Does token renewal work when a post is due?

Tools of the trade
1

  1. Set up a test with two independently connected accounts and one queued post for each. Record the job IDs and which account owns each credential. The second account is a control: its post should remain runnable even if the first account needs attention.

  2. Simulate an expired access token for the first account while leaving its refresh credential valid. Run its due job and check the log: was renewal attempted, was the replacement credential saved, and did the publish request retry with that credential? Some integrations renew before sending the request; others react to an authentication error. Either path is fine if the job reaches a clear final state. Log credential versions or IDs, not token values.

  3. Repeat with a refresh credential that cannot be used. The expected failure is narrow: pause jobs belonging to that account, surface an alert with the account identifier and renewal error, and leave the control account’s job runnable. Otherwise, every due job may keep making the same failed refresh request.

  4. Use this as the pass checklist: successful renewal leads to one recorded publish outcome; failed renewal stops repeat attempts for the affected account; the alert says what needs reconnecting; other accounts keep moving. If several jobs become due together, check that they do not all race to refresh the same credential.

How do you verify renewal behavior before trusting queued publishing: a test account, a simulated token failure, or another repeatable check?

2

Add one publish-timeout test: let the platform accept a queued post, then stop the worker before it records the result. On restart, treat the outcome as unknown. Reconcile it against the remote account, or use a platform-supported idempotency key before retrying. If neither can establish the outcome, hold the job rather than risk a duplicate post.

3

Persist the job as outcome_unknown before sending the publish request, along with an attempt ID and payload fingerprint. After a restart, route that state to reconciliation rather than the pending-job queue. That durable transition covers the gap where the platform accepts the post but the worker stops before recording the response.

If reconciliation finds the post, mark the job published and save its remote ID if available. Move it to retryable only when reconciliation confirms no remote post was created. If the check remains inconclusive, keep the job in outcome_unknown and hold it.