I have deployed a new pipeline for RESTBase in production and it all looks great. Next step - convert other services. I will try it out on change-prop and create subtasks for individual services.

If you could verify on Beta prior to deployment, however, that would be helpful.

The new UI has been deployed. Next step here - explore the new features in openAPI 3.0, see what we can start using, converting the specs into 3.0.

The https://gerrit.wikimedia.org/r/500363 fixes it. Don't want to self-merge my own patch though.

Thank you for catching this early and sorry for this.

If I understand correctly, in order to switch a particular job execution to PHP7 all we need to do is to add Cookie: PHP_ENGINE=php7 header to the request.

I think I have failed to describe the details of the basis of the reasoning behind this leaving a lot of room for confusion. I'll try to fix this mistake.

We have deployed the partitioner for the htmlCacheUpdate job and it's not running in production. We have created some lag in the process, but it should clear out soon.

After the patch was deployed we do not have nulls in recent change schema anymore, however we still can not declare victory and get rid of all of the polymorphic types in the schema. The log_params can be either an object or an array and, judging by the code, it can actually be a non-empty array in rare cases. Not sure what to do about that.

Actually, the existing topic need to be left alone, but 2 new topics 8 partitions each needs to be created:

Merged and deployed as a part of SWAT. Resolving.

For step 2 we need to switch hyperswitch to upstream swagger.

@Ottomata yes, but not just yet, we still need to prepare the patches etc.

There is already an ability to execute jobs after a delay or at more-or-less specific time, but it's really not something we want to build on.

Now it's ready - CP tests are independent of both Kafka and Redis.

mediawiki-vagrant should also be updated to support new proton role.

Oh, no, not resolving yet. Next step - mock redis.

The PR has been merged, resolving

Can this be resolved?

The rev_content_changed has been removed from the schema and after the train we will ensure rev_parent_id is present in all the events. Resolving.

I think that the schema is incorrect here.

After enabling logging over syslog for RESTBase in deployment-prep, we have identified a number of disparities between node services and, for example, mediawiki.

Verified that we can work with swagger-ui 3+ once we make the spec standard-compliant. Let's begin with modifying the specs.

I wonder if we should also use ?hasty=true mode for mediawiki 'analytics' events? This would use a non-ACKed producer and not ever block the MW waiting for a response.

Oh, we have made use of the hot-shots internal childClient method, but forgot there's a debugging LogStatsD. Need to fix this in service-runner and make sure RESTBase starts if we configure metrics.type to 'log'.

I think this is done and can be resolved now.

This seem to be a bug in swagger-ui. We're going to update to the latest upstream version of the package, so it should be resolved when done.

I think we have a consensus to go spec-compliant here. I've created a task for services and a special task for RESTBase, as it's a different beast. I'm resolving this ticket.

Well instead of copy/pasta, there is that thing called YAML anchors/references that deal with data repetition in YAML files.

I would say we should update our swagger to 3.0 and become standard-compatible.

Ye, it can be deleted. This is not used and has actually never been used.

The change has been deployed and EventBus doesn't fail with this anymore. Resolving.

Exactly. We have to prioritize T171788 I guess.

Thank you, everyone! :)

Taken care of by https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/EventBus/+/493073/

The above patch and backport should take care of this and another one with $eventServiceName issue. Sorry about that

Thank you a lot @hashar . I guess this ticket can be closed, however I have a last question - do you think we could somehow improve quibble to output this info without the need to place *cough* console.log()?

I'm not sure how Flow works internally, which hooks are called and why doesn't it set a user, better to ask Community-Tech ?

Parsoid was in a bit of trouble again today. At 02:44 XioNoX: depool eqsin, so all the mobile traffic for Chinese wiki started hitting RESTBase. Since Chinese has variants, RB started requesting Parsoid to transform HTML into correct variant. As the transformation request rate reached roughly 40 r/s, Parsoid started experiencing troubles, alerting and timing out.

I have tried to resubmit the change: https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/EventBus/+/491014/ with no luck.

This is a bug in Event-Platform. Serializing the events for sending is protected with a try-catch, it logs an error and drops the job if it's not serializable. However, in this case, it fails in a different place - each job is signed via JWT so that it could be checked in a later point and verified that Mediawiki is the entity actually sending the job. That signing procedure internally requires serialization as well apparently and it's not protected with try-catch.

Rejecting events that haven't lowercased the headers is another option, albeit not as user-friendly.

EventGate, so that all parts of the system have a standard representation of the headers.

It's still undecided what to do with package-lock (T179229), so maybe let's just freeze the verison?

KafkaSSE requires ^2.3.4.