test(server): NET-6719 allow scheduled_retry in legacy retry status check
The retry row created by enqueueProcessLossRetry is inserted with status 'scheduled_retry' (dueAt = now + 30s) and only promoted to 'queued'/'running' by promoteDueScheduledRetries once scheduledRetryAt has elapsed. The test query runs immediately after reapOrphanedRuns, so the observed status is most often 'scheduled_retry'. Expand the assertion to accept any of the three valid post-insert statuses.
This commit is contained in:
parent
035f4dd792
commit
d0cf099c5f
|
|
@ -2779,13 +2779,15 @@ describeEmbeddedPostgres("heartbeat orphaned process recovery", () => {
|
|||
}),
|
||||
});
|
||||
expect(failed?.stderrExcerpt ?? "").not.toContain("[environment-allocation]");
|
||||
// Legacy path enqueues an immediate retry (startNextQueuedRunForAgent may
|
||||
// transition it to "running" before we query, so we don't pin the status).
|
||||
// Legacy path enqueues an immediate retry. The retry row is inserted
|
||||
// with status "scheduled_retry" (dueAt = now + 30s) and only promoted by
|
||||
// promoteDueScheduledRetries once scheduledRetryAt has elapsed, so the
|
||||
// observed status here is one of: scheduled_retry, queued, or running.
|
||||
expect(retry).toMatchObject({
|
||||
retryOfRunId: runId,
|
||||
processLossRetryCount: 1,
|
||||
});
|
||||
expect(["queued", "running"]).toContain(retry?.status);
|
||||
expect(["scheduled_retry", "queued", "running"]).toContain(retry?.status);
|
||||
// Legacy path uses the immediate process_lost_retry wake reason, not the
|
||||
// bounded environment retry wake reason.
|
||||
expect(retry?.contextSnapshot).toMatchObject({
|
||||
|
|
|
|||
Loading…
Reference in New Issue