Aelira Core v0.9.5: Remediation that survives a restart

A course remediation run rarely fits into one clean transaction. It may touch many items, continue for hours, call an LMS repeatedly and outlive the worker that started it. Aelira Core v0.9.5 changes how that work is recorded and recovered. Jobs now retain enough state for an operator to understand an interruption, resume eligible work and review the effects that may already exist outside Aelira.

This is an operations release for teams that change institutional course content. It does not treat a successful process exit or a clean accessibility score as the whole record. The useful record connects the authorized scope, worker claims, attempts, managed artifacts and available evidence from external calls.

Aelira Core remains beta software. Canvas is the integration verified for this release. Brightspace remains beta, while Blackboard and Moodle are experimental. Those labels matter because each LMS has different permissions, content models and failure behavior. Evidence from Canvas does not transfer automatically to another connector.

A representative run

Consider an accessibility lead who approves remediation for a defined set of files in one Canvas course. The operator confirms the course and item selection before the job enters the queue. Aelira stores that scope with the job rather than leaving it in a transient browser session or worker process.

A worker claims the first bounded unit of work. Its claim has an owner, a heartbeat and a fence. The fence matters when timing becomes awkward. If the worker stalls long enough for its claim to expire, another worker can take over without allowing the old worker to carry on as though it still owns the item.

Partway through the run, the host restarts. Some items are complete, one external request has an uncertain outcome and the remaining items have not begun. When services return, Aelira reads the persisted job state. It does not erase the run and start every item again. Completed work stays complete. Eligible unstarted work can return to processing. The uncertain external request remains visible for operator review rather than being converted into a silent success.

The operator checks the run record and compares the available LMS evidence with the managed artifact linked to that attempt. If the external effect can be established, the operator records the disposition and continues. If it cannot, the institution can apply its own review policy before another write occurs. That decision remains attached to the run.

The run eventually finishes with a history that explains more than the final count. It shows who authorized the scope, which worker held each claim, when ownership changed, which attempts failed, what was retried, which artifacts were produced and where an external effect needed human judgment. This is the practical difference between a background task and a recoverable institutional workflow.

What changed in v0.9.5

The durable queue processes defined units of work across multiple workers. Claims use fencing so a stale worker cannot keep acting after ownership has moved. Heartbeats make liveness visible. Retry limits prevent a persistent failure from cycling forever, and dedupe controls reduce repeated processing where the system has enough information to identify it.

Recovery uses persisted state after a worker crash or host restart. The system can distinguish work that is complete, work that can continue and work that needs attention. It preserves uncertainty when an external system may have accepted a request but the response did not return. That is safer than guessing, but it still requires an operator to resolve some cases.

Managed artifacts now belong to the job lifecycle. A generated or transformed file keeps a stable relationship to the run and attempt that produced it. This helps operators inspect results after recovery and gives reviewers a clearer path from an authorized job to the material created during it.

The release also improves run evidence around external effects. That evidence can support incident review, change review and local audit work. It does not replace an institution's retention policy, access controls or legal assessment. It gives those processes a more useful technical record.

Batch remediation has been exercised with many items. The exact verified boundary for this release is 1,000 items. That test covered the boundary Aelira reports; it does not establish capacity beyond it or prove every deployment topology.

Release artifacts are signed and the release includes seven software bills of materials. Operators can use those materials during their own supply-chain and deployment review. They do not replace local verification of images, configuration, dependencies or controls.

Operator upgrade steps

Existing v0.9.4 operators should schedule the upgrade as a controlled change. Preserve every v0.9.4 action and record before migration. Do not clear, rewrite or discard old job history to make the new queue look tidy.

1. Stop new remediation work and allow active work to reach a known state. Record any run that still has an uncertain external effect.
2. Back up PostgreSQL and verify that the backup is readable. Keep the backup until the migrated deployment and its recovery path have been checked.
3. Record the exact application images and configuration used before the upgrade. A database rollback may also require those matching pre-upgrade images.
4. Run the database migration explicitly:

docker compose -f docker-compose.prod.yml run --rm --entrypoint alembic api upgrade head

1. Start the upgraded API and worker services. Confirm both API and worker health before allowing any remediation work.
2. Inspect jobs and rows quarantined from the older model. Do not reset quarantined old rows to pending. The new system cannot safely infer prior ownership, progress or external effects. Review each row and record whether to close it or create deliberately authorized new work.
3. Run a bounded verification job in a test course or approved low-risk scope. Check claim history, recovery behavior, artifacts and external-effect evidence before reopening normal work.

Plan rollback before migration. Restoring only application images may be insufficient after the schema changes. A rollback may require the verified pre-upgrade PostgreSQL backup together with the matching pre-upgrade images and configuration. Test that path in the environment where the institution expects to use it. If API or worker health fails after migration, keep remediation stopped and investigate rather than resetting queue state.

Integration and licensing boundaries

Canvas is the verified integration in v0.9.5. The verification covers the release's Canvas workflow, including job handling, managed artifacts and evidence capture. Institutions still need to test their own roles, credentials, course structures, network behavior and change controls.

Brightspace is beta. Blackboard and Moodle are experimental. Use a bounded evaluation scope for those connectors, verify permissions against the current platform and do not treat the Canvas result as evidence that another LMS behaves the same way.

Aelira Core is licensed under AGPL-3.0. If an operator modifies the covered program and offers that modified version for users to interact with over a network, AGPL section 13 requires an offer of the corresponding source to those users. Distribution creates separate AGPL obligations. These points are a practical description, not legal advice; institutions should have counsel review the license and their intended deployment.

The Aelira CLI is licensed separately under MIT. Its license does not change the license that applies to Aelira Core.

Limits to carry into rollout

v0.9.5 improves recovery, but it does not promise exactly-once effects in every external system. A network can fail after an LMS accepts a write and before Aelira receives the response. The release records the uncertainty so an operator can investigate it.

The 1,000-item result is a tested boundary, not a capacity guarantee for every combination of hardware, content and LMS behavior. Canvas verification does not raise the maturity of the other connectors. Signed artifacts and SBOMs support review but do not certify a deployment. Run evidence supports institutional governance but does not guarantee compliance or a legal outcome.

Accessibility specialists still need to review changes where meaning, reading order, alternative text or instructional intent depends on context. Operators remain responsible for credential scope, monitoring, backups, retention and rollback. Start with a bounded scope that reflects the institution's own environment and approval process.

Release information

The primary reference is the v0.9.5 release notes and operator instructions. Existing operators should complete the backup, migration, health, quarantine and rollback checks before resuming remediation.

Secondary links: Aelira Core repository and Aelira CLI on npm.