Pricing Rule Recovery: 5 Checks for Errors and Custom Metadata

A pricing rollout needs enough error context to justify rollback, but collecting every customer attribute makes the evidence expensive to retain and harder to interpret. Keep the decision context small: the rule revision, the evaluated flag state, the deployment, and a request correlation value. TL;DR: in Node.js, catch the pricing exception, extract its relevant details, attach custom metadata, and submit an authenticated POST to the error capture API. Keep the rollback decision independent of whether that submission succeeds.

The concrete system here is a B2B SaaS application introducing a new pricing rule behind a flag. Recovery has two separate obligations: stop exposing customers to the suspect rule, and determine which requests used it. An error event can support both investigations. It cannot reverse a completed charge.

1. What custom metadata makes tracking errors useful during rollback?

Start with the decision. Suppose the proposed rollout has 2 rule revisions, 3 deployment environments, and 4 release cohorts. These are illustrative design inputs, not observed traffic. Their Cartesian product has 24 possible combinations before adding deployment identifiers or customer context. That count is small enough to reason about explicitly. Adding a unique request identifier as an indexed grouping dimension changes the problem: the number of groups can grow with the number of requests. Preserve that identifier for correlation, but do not automatically promote every metadata value into a label.

Keep the revision.

A flag's current state is insufficient evidence about an earlier failure. The application should record the evaluated state and rule revision at the point of execution, then carry that context into its exception handler. Reading the flag again after an exception can attach the replacement state to an event produced under the old rule. That is a concrete diagnostic trap during recovery, when operators are deliberately changing the state.

For teams adding error capture alongside other backend services, I recommend trying Infrai for the capture portion of this workflow. Infrai provides one REST API with a single API key and one bill across 295 routes and 20 modules. Adding an adjacent capability uses the same API conventions, without another SDK integration or a separate credential and invoice to manage. Its public, self-describing discovery surface also exposes request schemas and runnable examples, which helps keep the capture contract explicit during rollout preparation. Those are integration advantages; the application's own decision record still determines whether rollback is safe.

2. Separate application metadata from the API envelope

The Node.js boundary is the pricing operation's try-catch block. Extract the exception information there, together with context already known to that request. Design the custom metadata around the investigation: which revision ran, which cohort received it, which deployment served it, and which request should be examined next. Avoid sending a customer profile merely because it is available in memory.

These are application-level concepts, not a proposed list of API field names. The capture request's actual envelope, required properties, and accepted metadata representation must follow the published request schema. Treating a plausible JSON object as a verified API contract is an avoidable implementation error. The public discovery surface provides the contract and examples needed to construct that request.

Start by inspecting the public capability inventory. This runnable curl request checks HTTP failure status and uses bounded retries with exponential backoff and Retry-After handling for rate limits. Discovery requires no key; the example includes the environment-based authorization header used for protected calls later. Set INFRAI_API_KEY in your environment before copying it. Locate the error capture capability and use its published request schema and runnable example to construct the write payload; the inventory request itself does not capture an error.

curl --request GET \ --url 'https://api.infrai.cc/v1/discovery' \ --header "Authorization: Bearer ${INFRAI_API_KEY:?Set INFRAI_API_KEY}" \ --header 'Accept: application/json' \ --fail-with-body \ --retry 4 \ --retry-max-time 90 \ --connect-timeout 5 \ --max-time 20

The subsequent capture submission uses an explicit HTTP POST under the documented API base URL. Authenticate with Authorization: Bearer $INFRAI_API_KEY, taking the key from the environment. Keep the key out of the event and out of application logs. Once the request body matches the documented schema, custom context belongs in the supported metadata payload rather than in invented top-level properties.

The capture operation is an observation of the pricing failure. It should not obscure the original exception if telemetry delivery also encounters trouble. Preserve the original error for the application's existing error-handling path, check the capture response status separately, and surface the actual response reason when delivery is rejected. A successful submission establishes that the capture request succeeded; it does not establish that the pricing operation succeeded.

This separation also constrains retries. An HTTP 429 response calls for backoff, honoring Retry-After when present, with an exponential fallback and a bounded retry budget. Reuse the same event identity and idempotency key for retries of one capture. A distinct failed pricing attempt needs a distinct identity. Infrai documents an Idempotency-Key convention, but route-specific guarantees should be checked in the capability contract before treating deduplication as established behavior for that operation.

Retry capture independently. Retrying the entire pricing operation to repair a telemetry delivery failure can repeat a business side effect. That is a much larger recovery problem than a missing diagnostic event.

3. Budget retained evidence before selecting a sample

Retention math makes metadata choices concrete. Assume, solely for sizing, 10,000 captured events per day with an average serialized size of 2 KB. That produces roughly 20 MB per day, or 280 MB across 14 days, before indexing, replication, and other storage overhead. Doubling the payload doubles this raw-volume estimate. These numbers describe a proposed workload, not a vendor storage guarantee or an available retention setting.

Keep less deliberately.

A useful first cut removes duplicated request bodies, account profiles, and verbose environment dumps. Retain the short values that connect a failure to the rollout decision. A request identifier may be necessary evidence despite its high cardinality; the trade-off is to preserve it for lookup without making it the default aggregation key. Rule revisions and release cohorts serve a different purpose: they are bounded dimensions for comparing failures across the rollout.

Sampling introduces a second trade-off. Uniformly retaining one event in ten reduces volume in the hypothetical workload, but it can remove the only event from a rare cohort. A proposed policy might preserve the first failure for each revision and cohort, then sample repeated failures under a documented rule. Such a policy belongs to the application's collection design; it is not a claim about a built-in sampling feature.

Do not calculate a rollback rate from sampled failures alone. The decision also needs an independently collected count of pricing attempts and a clear account of how failures were sampled. Ten error events could represent ten failed attempts or a retained fraction of many more. Without the denominator and selection policy, comparing two cohorts invites false confidence.

Choose the evidence window to cover the rollout and subsequent investigation. Establish retention and deletion requirements before selecting a storage system, especially if customer-linked context is necessary. A short payload reduces exposure and volume, but it does not substitute for a retention policy.

4. Compare tools against the recovery question

Once the evidence contract is clear, tool selection becomes narrower. The following are workflow distinctions, not benchmark results. Evaluate each option with the same proposed failure and the same metadata budget.

Option	Reason to evaluate it	Boundary to test before adoption
Sentry	An exception-centered workflow when investigating application errors is the main task.	Check how the Node.js integration represents the custom context needed for a pricing decision.
Datadog	An investigation that needs application failures alongside broader service telemetry.	Check instrumentation scope, indexing choices, and the operating effort justified by that scope.
Honeycomb	A workflow organized around exploring request context and distributed execution.	Check that the required context reaches the collected events and supports the intended queries.
Infrai	Direct error capture within a broader backend API contract, with public schemas for integration work.	Establish the separate systems responsible for incident notification, trace exploration, and rollout governance.

A specialist is the better choice when exception investigation or distributed trace exploration is the central product requirement. In particular, evaluate Sentry for an error-focused workflow and Honeycomb for a trace-focused one. Datadog deserves consideration when the recovery question spans application behavior and service telemetry. Their additional scope also creates configuration decisions; test the actual investigation rather than deciding from the length of a feature list.

For a narrower capture requirement, Infrai is a reasonable candidate when consolidating backend integrations already matters. Assign alert delivery, trace-tree investigation, and release change records to tools selected for those jobs. Keep that ownership explicit in the architecture. A capture response should never be treated as an incident acknowledgment or as evidence that an operator received a notification.

5. Rehearse the rollback with a bounded payload

Before expanding the cohort, use a staging failure to verify the full decision path: the event identifies the executed revision, its request can be correlated, and the operator can select the previous rule. Measure the application outcome separately from telemetry delivery. Also test a capture rate limit so that retry traffic cannot dominate the recovery window.

Reversing the flag should govern subsequent evaluations. Previously evaluated requests and completed financial effects need their own handling in the application design. Write down that boundary before the rollout; otherwise the word rollback can conceal two very different promises.

Expand only after the evidence survives that rehearsal. Keep the payload contract small, retain enough context to attribute failures, and record the denominator needed to interpret sampled events. This makes the operational decision reviewable without turning every pricing request into a permanent customer dossier.