BackWave 1.8.0-preview.2

BackWave 1.8.0-preview.2

This is a prerelease. The headline is Reschedule: an operator can move the due time of a waiting job and keep the job. The release also stops an Oracle worker group from halting when the database becomes unreachable.

Install the prerelease:

dotnet add package BackWave --prerelease

Use the same version for every BackWave package in the app.

Added

Reschedule a waiting job

BackWaveOperator.RescheduleAsync moves the due time of a Scheduled or AwaitingParent job. The job keeps its id, payload, queue, attempt, and Retry Cause. Before this release, the only way to move a job was to cancel it and enqueue a new one.

var result = await backWaveOperator.RescheduleAsync(campaign.SendJobId, newSendAt, actor: userId);
if (result == RescheduleResult.NotReschedulable)
{
    // The campaign is already sending or sent.
}

Things to know:

• A running, finished, or unknown job returns NotReschedulable and does not change. So this result means that it is too late to move the job.
• A job that waits on parents starts no earlier than the new due time after its parents finish. A due time at or before now makes the job run when a worker is free.
• Pass a DbTransaction to move the job in the same transaction as your own writes. BackWave.EntityFrameworkCore adds an overload that takes a DbContext. Keep the transaction short: the job row stays locked until you commit.
• The action writes one operator audit record with the old and the new due time (RescheduleAuditDetail(From, To)), and no transition. The MCP audit rows show them as rescheduledFrom and rescheduledTo.
• A move to a due instant sends the Wake-Up Hint on Postgres, Oracle, and SQLite, so an idle worker claims the job at once.
• All five first-party stores implement it. IJobStore.RescheduleAsync is a default interface member, so a custom store still compiles. It throws NotSupportedException until the store implements it.

To try it, run the sample and call POST /ops/jobs/{id}/reschedule?seconds=60 on a Scheduled job.

Changed

• Schema. Each SQL adapter adds one additive migration: a nullable detail column on the operator audit table. Postgres and Oracle go to schema version 3, SQL Server and SQLite to version 4. With AutoMigrate on, the store applies it on first use.
• Oracle: when the database is unreachable, the store retries its first-use migration for 5 s at most, then the worker group tries again on its next poll. Before, one slow host blocked every store call for the full retry.
• CAUTION: Make sure that the Oracle Data Source is correct before you deploy. A host name that does not resolve, a wrong service name, or a wrong TNS alias now leaves the worker group degraded and polling, and does not halt it. These faults give the same codes as a real outage. A rejected login (ORA-01017) and a wrong connection string attribute still halt the group. The Postgres adapter already behaves this way.

Fixed

• Oracle: a worker group halted when the database became unreachable, for example with ORA-12545 when the host name stopped resolving (#12). The adapter now marks the outage and restart faults transient: ORA-12545, ORA-50201 (connection refused), ORA-50000 (connect timeout), ORA-50012 (pool exhausted), ORA-01089, and ORA-01109. The group degrades, polls again, and runs jobs when the database answers.
• Oracle: when several nodes migrated a new schema at the same time, one of them could fail to start with ORA-04020 (a library cache deadlock). The migrator now retries it, and the worker group degrades on it and does not halt.
• Oracle: the claim now checks the due time again at the row lock, so it never claims a job whose due time moved after the job was selected.

All 14 packages ship at 1.8.0-preview.2 on nuget.org.