New SQL table for tracking neat_periodic_task statuses (mirror-only for now).

[isoos]

No description provided.

[jonasfj]

I think this can migrate atomically, can it not? In these use cases do we care if it runs one more time? Do we even have any that aren't runtimeVersioned? It's not globalLock and even that I think it would only matter for those that are globallock and not runtimeVersioned.

…

-- Regards Jonas Finnemann Jensen. fre. 14. aug. 2026, 16.46 skrev István Soós ***@***.***>:

@isoos <https://github.com/isoos> requested your review on: dart-lang/pub-dev#9534 <#9534> New SQL table for tracking neat_periodic_task statuses (mirror-only for now).. — Reply to this email directly, view it on GitHub <#9534?email_source=notifications&email_token=AABERZEAW5UDN4KFQYESOJ35J4Q3XA5CNFSNUABQM5UWIORPF5TWS5BNNB2WEL2JONZXKZKFOZSW45CON52GSZTJMNQXI2LPNYXTEOJUGY2DKNBSHE4TPJTSMVQXG33OWBZGK5TJMV3V64TFOF2WK43UMVSKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#event-29464542997>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABERZBVSGKH7YMA4ZYE3ML5J4Q3XAVCNFSNUABEKJSXA33TNF2G64TZHMZDQMBTGU3TKNR3JFZXG5LFHM2TCNJSHAZDCNZTGGQXMAQ> . You are receiving this because your review was requested.Message ID: ***@***.***>

[isoos]

Sure, we could do this in a single migration too, though, some non-runtimeVersioned jobs are a bit heavy.

As an alternative (which could also work for global lock) we could just start using the SQL as the authoritive source, and write the status/lock back to Datastore without considering the status there. The old process may correctly assume that something is running it (for most of the time).

I'll update the PR to do that migration and mirror the state to Datastore.

[jonasfj]

What jobs are problematic to run twice as often as we do? It's more concerning if racing is a problem...

…

-- Regards Jonas Finnemann Jensen. fre. 14. aug. 2026, 17.06 skrev István Soós ***@***.***>:

*isoos* left a comment (dart-lang/pub-dev#9534) <#9534 (comment)> Sure, we could do this in a single migration too, though, some non-runtimeVersioned jobs are a bit heavy. As an alternative (which could also work for global lock) we could just start using the SQL as the authoritive source, and write the status/lock back to Datastore without considering the status there. The old process may correctly assume that something is running it (for most of the time). I'll update the PR to do that migration and mirror the state to Datastore. — Reply to this email directly, view it on GitHub <#9534?email_source=notifications&email_token=AABERZCUH3FPH3EYGH7SAOT5J4TIFA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMRZGQ4DKNRWGMY2M4TFMFZW63VQOJSXM2LFO5PXEZLROVSXG5DFMSSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5294856631>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABERZBIZYISLDXWB5YBT7L5J4TIFAVCNFSNUABEKJSXA33TNF2G64TZHMZDQMBTGU3TKNR3JFZXG5LFHM2TCNJSHAZDCNZTGGQXMAQ> . You are receiving this because your review was requested.Message ID: ***@***.***>

[isoos]

What jobs are problematic to run twice as often as we do?
It's more concerning if racing is a problem...

The tarball- and the datastore- integrity (both weekly) checks are the most heavy, not sure about the synchronizing exported API (daily) task.

[isoos]

PTAL: updated the PR with the version where SQL is the primary store and Datastore is updated so that old runtimeVersion would not try to run the task concurrently.