Problem
apimatic sdk publish only reports telemetry when the publishing API rejects the publish request. SdkPublishAction calls onPublishSdkError in exactly one place:
https://github.com/apimatic/apimatic-cli/blob/dev/src/actions/sdk/publish.ts#L95-L99
if (publishSdkResponse.isErr()) {
this.prompts.sdkPublishingServiceError(publishSdkResponse.error);
onPublishSdkError(publishSdkResponse.error.errorMessage);
return ActionResult.failed();
}which fires SdkPublishValidationFailedEvent (400/403/404, auth, validation).
Nothing is tracked for the case where the request is accepted and publishing then terminates in Failed, Exception, or InternalError, nor for a getSdkPublishingLog error that ends the poll. The CLI observes these outcomes — it prints them and exits 1 — but never reports them, so the failure rate of publishes that actually reached the publishing service is invisible.
Why it wasn't folded into the existing event
SdkPublishValidationFailedEvent models a rejected publish request, and its message carries a real service error string. A post-acceptance failure has no equivalent message (only per-target eventType values), and routing it through an event named …ValidationFailed would mean that metric silently stops meaning one thing.
Suggested shape
- A dedicated event, e.g.
SdkPublishFailedEvent extends DomainEvent, with a message summarising which targets failed and with what eventType.
- A second callback threaded from
commands/sdk/publish.ts through both mode actions into SdkPublishAction, alongside the existing onPublishSdkError.
- Decide whether a status-fetch error (outcome unknown) is reported as the same event, a distinct one, or not at all — it is not a publish failure, and conflating it would inflate the failure rate.
Context
Both interactive and non-interactive sdk publish now poll to a terminal state, so both modes reach this untracked failure path. Deliberately left out of the change that added polling to interactive mode, to keep that a behavioral-parity fix. Related: #312.
Problem
apimatic sdk publishonly reports telemetry when the publishing API rejects the publish request.SdkPublishActioncallsonPublishSdkErrorin exactly one place:https://github.com/apimatic/apimatic-cli/blob/dev/src/actions/sdk/publish.ts#L95-L99
which fires
SdkPublishValidationFailedEvent(400/403/404, auth, validation).Nothing is tracked for the case where the request is accepted and publishing then terminates in
Failed,Exception, orInternalError, nor for agetSdkPublishingLogerror that ends the poll. The CLI observes these outcomes — it prints them and exits1— but never reports them, so the failure rate of publishes that actually reached the publishing service is invisible.Why it wasn't folded into the existing event
SdkPublishValidationFailedEventmodels a rejected publish request, and itsmessagecarries a real service error string. A post-acceptance failure has no equivalent message (only per-targeteventTypevalues), and routing it through an event named…ValidationFailedwould mean that metric silently stops meaning one thing.Suggested shape
SdkPublishFailedEvent extends DomainEvent, with a message summarising which targets failed and with whateventType.commands/sdk/publish.tsthrough both mode actions intoSdkPublishAction, alongside the existingonPublishSdkError.Context
Both interactive and non-interactive
sdk publishnow poll to a terminal state, so both modes reach this untracked failure path. Deliberately left out of the change that added polling to interactive mode, to keep that a behavioral-parity fix. Related: #312.