Bug 1620697 Comment 13 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Brainstorming:

1. `notarization_poller` should store a timestamp with each uuid. We could get this in various ways: from the task resolution time, `claimWork` time for the poller task, or we could populate the `uuid_manifest.json` with a dictionary (`{uuid: timestamp}`) instead of a list-of-uuids. I'm leaning towards the manifest solution. The `claimWork` time is easiest to use, but we may wait a lot more time than needed if someone cancels and reruns a long-running poller task, for example.
2. Because all of a given task's UUIDs are stored in the same `Task` object, we know when a given UUID in a task is taking longer than the others. We could potentially store polling statuses in the same dictionary.
    a. The UUID could be an object with the submission timestamp and polling statuses?
3. All running tasks are stored in `RunTasks.running_tasks`. By inspecting each Task object, we could make an educated guess if we're seeing a single UUID that's taking way too long to notarize, or if Apple's notarization service is generally being slow.
Brainstorming:

1. `notarization_poller` should store a timestamp with each uuid. We could get this in various ways: from the task resolution time, `claimWork` time for the poller task, or we could populate the `uuid_manifest.json` with a dictionary (`{uuid: timestamp}`) instead of a list-of-uuids. I'm leaning towards the manifest solution. The `claimWork` time is easiest to use, but we may wait a lot more time than needed if someone cancels and reruns a long-running poller task, for example.
2. Because all of a given task's UUIDs are stored in the same `Task` object, we know when a given UUID in a task is taking longer than the others. We could potentially store polling statuses in the same dictionary.
    a. The UUID could be an object with the submission timestamp and polling statuses?
3. All running tasks are stored in `RunTasks.running_tasks`. By inspecting each Task object, we could make an educated guess if we're seeing a single UUID that's taking way too long to notarize, or if Apple's notarization service is generally being slow.
4. If there's a single UUID that's taking way too long to notarize, we can then download the signed app from the notarization-part-1 task, and try re-notarizing it. (I'm not sure if we should throw away the first UUID, or poll both and go green if either one of the UUIDs is successful. In theory we should be able to do the latter, since we haven't changed the signed bits at all, just the notarization request. We haven't noticed a UUID that goes missing and is later valid, however.) Then we can poll for that UUID and repeat.

Back to Bug 1620697 Comment 13