Good First Issue
Add a scenario diagnostics-upload-success. It is a negative control: a station
that uploads diagnostics successfully must produce no failures.
diagnostics-failure.ts is the only scenario that sends a
DiagnosticsStatusNotification at all, and it sends only a failing status. Nothing
covers the successful path, so a change that widened DIAGNOSTICS_FAILURE to treat
Uploaded or Uploading as a problem would pass the whole suite while reporting
every healthy diagnostics upload as a fault.
What to do
- Create
packages/toolkit/src/scenarios/__scenarios__/diagnostics-upload-success.ts
- Build a synthetic trace of a clean diagnostics upload:
BootNotification at 2026-03-01T10:00:00.000Z, and its CallResult with
interval: 300
DiagnosticsStatusNotification with { status: 'Uploading' } at
10:01:00.000Z, and its CallResult
DiagnosticsStatusNotification with { status: 'Uploaded' } at
10:02:00.000Z, and its CallResult
Heartbeat at 10:04:00.000Z, and its CallResult
- Set
expectedFailures: []
- Add
{ type: 'no_failures', params: {} } as the assertion
- Register, update the counts, run the checks and add a patch changeset
Why those statuses
Uploading and Uploaded are the progress and success values a station reports on
a healthy diagnostics upload. Keeping the whole trace inside five minutes of the
boot keeps the heartbeat rules quiet. This trace was run against the detection
engine and reports no failures.
Files to modify
The same seven as Issue A, with the new file named
diagnostics-upload-success.ts.
Guidelines
- Reserves station ID
CS-SYNTHETIC-026.
firmware-update-success.ts is the closest existing negative control to copy,
since it is the same shape for the firmware equivalent.
- Verify with
ocpp-debugkit scenario run diagnostics-upload-success that no
failures are reported. If a rule fires, fix the trace rather than adding the code
to expectedFailures. Staying clean is the whole point.
- Everything else as in Issue A.
How to claim
Comment "I'd like to work on this" and it will be assigned to you.
Please hold one open claim at a time. Once the pull request for it is merged, say
which issue you want next and it will be assigned.
Good First Issue
Add a scenario
diagnostics-upload-success. It is a negative control: a stationthat uploads diagnostics successfully must produce no failures.
diagnostics-failure.tsis the only scenario that sends aDiagnosticsStatusNotificationat all, and it sends only a failing status. Nothingcovers the successful path, so a change that widened
DIAGNOSTICS_FAILUREto treatUploadedorUploadingas a problem would pass the whole suite while reportingevery healthy diagnostics upload as a fault.
What to do
packages/toolkit/src/scenarios/__scenarios__/diagnostics-upload-success.tsBootNotificationat2026-03-01T10:00:00.000Z, and itsCallResultwithinterval: 300DiagnosticsStatusNotificationwith{ status: 'Uploading' }at10:01:00.000Z, and itsCallResultDiagnosticsStatusNotificationwith{ status: 'Uploaded' }at10:02:00.000Z, and itsCallResultHeartbeatat10:04:00.000Z, and itsCallResultexpectedFailures: []{ type: 'no_failures', params: {} }as the assertionWhy those statuses
UploadingandUploadedare the progress and success values a station reports ona healthy diagnostics upload. Keeping the whole trace inside five minutes of the
boot keeps the heartbeat rules quiet. This trace was run against the detection
engine and reports no failures.
Files to modify
The same seven as Issue A, with the new file named
diagnostics-upload-success.ts.Guidelines
CS-SYNTHETIC-026.firmware-update-success.tsis the closest existing negative control to copy,since it is the same shape for the firmware equivalent.
ocpp-debugkit scenario run diagnostics-upload-successthat nofailures are reported. If a rule fires, fix the trace rather than adding the code
to
expectedFailures. Staying clean is the whole point.How to claim
Comment "I'd like to work on this" and it will be assigned to you.
Please hold one open claim at a time. Once the pull request for it is merged, say
which issue you want next and it will be assigned.