| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
There was a problem hiding this comment.
Warning
The primary telemetry payload lacks direct unit-test coverage for its field name and nesting.
1 open finding What changed in this PRAdds the originating proxy release version to successful start-proxy telemetry.
Changes:
| File | Description |
|---|---|
| src/start-proxy/status-report.ts | Defines proxy telemetry and reporting. |
| src/start-proxy/status-report.test.ts | Relocates failure-report tests. |
| src/start-proxy.ts | Returns proxy path and version. |
| src/start-proxy.test.ts | Verifies resolved proxy versions. |
| src/start-proxy-action.ts | Sends the version in success telemetry. |
| lib/entry-points.js | Generated bundle; content excluded from review. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Sorry, something went wrong.
| t.is(sendStatusReport.callCount, 1); | ||
| t.is(sendStatusReport.args[0].length, 1); | ||
|
|
||
| const arg = sendStatusReport.args[0][0]; | ||
| t.like(arg, { | ||
| action_name: statusReport.ActionName.StartProxy, | ||
| registry_types: "docker_registry,git_source", | ||
| start_proxy: { proxy_version }, | ||
| }); |
There was a problem hiding this comment.
Would calledOnceWithExactly work here?
Sorry, something went wrong.
There was a problem hiding this comment.
Yeah, but I don't like the sinon assertions because they only return true/false and so if the assertion fails we don't know why. The t.like will print a nice diff if the assertion fails.
Sorry, something went wrong.
There was a problem hiding this comment.
I think if we use sinon.assert.calledOnceWithExactly instead of sendStatusReport.calledOnceWithExactly we'll get a good error message if the assertion fails. It's non-blocking, though.
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Extends start-proxy's success telemetry with the version of the release that the proxy binary came from.
Risk assessment
For internal use only. Please select the risk level of this change:
Which use cases does this change impact?
Workflow types:
Products:
Environments:
How did/will you validate this change?
If something goes wrong after this change is released, what are the mitigation and rollback strategies?
How will you know if something goes wrong after this change is released?
Are there any special considerations for merging or releasing this change?
Merge / deployment checklist