Marx: preserving an uncertain submission
Preserve local recovery state without assuming what a remote scanner accepted.
A desktop process can stop after asking a remote service to do work and before receiving a usable answer. Restarting the process does not tell it whether that request succeeded. In Marx, the local workbench runs the official Checkmarx CLI while analysis happens remotely. Repeating a source submission to make the interface look recovered could create another scan without resolving the first one. The implementation preserves that uncertainty as information the next action needs.
Recover what the record can establish
On startup, the native engine reads durable jobs. An unfinished job becomes Unknown, its local monitoring stops, and its saved explanation asks the reader to reconcile known scan IDs and check Checkmarx One before retrying an uncertain submission. Recovery uses known remote identifiers. The pinned TestRestartRecoveryUsesKnownIDsOnly fixture creates one job with a scan ID and another without one: the known job reconciles, the uncertain job remains Unknown, and recovery must not create the synthetic submission marker.
That test specifies a useful boundary. Persistence establishes that the application remembers its local work; it does not establish that the scanner accepted a request. A known scan identifier supplies a way to ask the remote system about particular work. Without that identifier, a confident retry would be a new action based on incomplete evidence. Keeping an unresolved row costs attention and may require manual investigation, but it retains the distinction between losing monitoring and losing the remote operation.
Carry that distinction into remediation
The same separation matters after a scan completes. Marx keeps original remediation evidence pinned and local decisions separate from scanner state. Its assistant handoff asks for commit or patch references, changed files, checks actually executed, and unresolved finding IDs. It also warns that a finding absent from a later scan needs comparable coverage and effective configuration before it supports verified remediation. A local decision records a review judgment; a later observation supplies different evidence. Combining them into one reassuring status would discard the reason a reader should trust or question it.
The transferable design lesson is to give each claim its own record and transition: local job durability, remote scan evidence, review decisions, and qualified verification. The extra states make the interface more demanding. They also let recovery and review proceed without manufacturing certainty. The dated acceptance record documents synthetic native checks and public-CVE lookups, while live Checkmarx tenant verification still needs an API key. Those observations do not establish tenant compatibility or a production-qualified release.
A suggested ten-minute reader check
Open the pinned engine and recovery test below. Trace the startup transition, then compare the two fixture jobs and the assertion against a new submission. Expect the job without a scan ID to survive as Unknown; expect reconciliation only for known work. Next inspect the handoff requirements for a later scan. This is a source inspection of the recovery contract, not a live submission test. It cannot establish how an approved tenant behaves during interruption, or whether a particular code change fixes a vulnerability.
Pinned recovery fixture and assertions