Bug 1397373 - superseding docs are now in the queue

[djmitche]

No description provided.

[petemoore]

Let's chat about this. I understand why you've done this, but I'm a little uncomfortable with it, as it is only by convention that two of our workers implement this way, and it seems like we lose something by hiding the fact that superseding can be implemented however the worker wishes.

I would say, if we want to enforce this is how superseding is implemented, we should move the supersededUrl out of the task payload into the root of the task definition, and update the worker-queue interaction docs to explain the responsibility of the worker to implement the feature. Although it has caused some pain that workers have implemented some things differently, it is great that we have a means for different workers to try out different types of features, and we're able to roll them out or change them independently. So for me, I'd still prefer to keep the supersederUrl in the task payload.

I can imagine a worker that doesn't refer to an external service to determine if a task is superseded or not (e.g. a worker running as a service, like buildbot bridge).

[djmitche]

Where would you suggest the documentation go?

[petemoore]

I'm not 100% sure, but I think I'd still like it in the worker docs, and the queue docs just to say what the task resolution reason "superseded" means semantically, but refer the user to the specific worker docs for implementation details. We could highlight in generic-worker and docker-worker docs that the implementation is the same as the other, if we want to save the user from needing to discover that after reading both.

[djmitche]

Could this be a recommendation from the queue? I'd like for taskcluster-worker, or whatever follows it, to feel encouraged to do something similar!

[djmitche]

I updated this to be a recommendation in the queue.

[petemoore]

Thanks Dustin!

[djmitche]

Thanks for your help :)