A failure your code swallows never reaches Déjà.

A Sentry issue, and one line of it decides.

What the pipeline does with a Sentry delivery, one step per row, with the function that does it. A log line is not a Sentry issue, and nothing here reads one.

Deliveries scored

Sentry's issue and error webhooks, the two the Sentry connection asks you to enable. An alert-rule notification is logged and not scored, so a Sentry alert rule is not a way to forward a failure.

sentry/event-router.ts · routeSentryEvent · sentry/alert-handler.ts · handleAlertEvent

What scoring is given

The issue's title, id, project slug, event type and time. Tags, extra data, the user and the stack trace are not scoring inputs.

sentry/issue-handler.ts · handleIssueEvent · sde-phase1-queue.ts · runSentryPhase1Job

The title

The issue title as Sentry sends it, which Sentry builds from the exception's type, a colon, and the first line of its message. A delivery with no title falls back to the first exception's type and message.

sentry/event-router.ts · exceptionTitle

Error type

The title up to its first colon or space. It scores the error-type factor, W4: a missing-field name (KeyError, AttributeError, MissingFieldError) matches a removed or renamed field; a type name (TypeError, ValueError, ValidationError) matches a changed type, except a JavaScript TypeError from reading a property, which counts as a missing field.

sde-phase1-queue.ts · runSentryPhase1Job · sde/ccs-math-engine.ts · classifyError

The field

The property a JavaScript engine names in (reading 'x'), Cannot read property 'x' of, or Safari's evaluating 'obj.x'. Otherwise the first quoted word in the title: two or more letters, digits, _, . or -. If that word is capitalised like a class name ('NoneType'), no quoted word is used. Otherwise a bare Python KeyError: x.

sde-phase2-deduction.ts · extractMissingField

No field found

No change is scored. The receipt is a no-attribution receipt (R1-N) whose reason is no_field_extracted.

sde-phase2-deduction.ts · runSdePhase2DeductionInner

Candidates

Recorded changes to that field, under the name as written or its snake_case or camelCase form, from the last 30 days.

sde-phase2-deduction.ts · runSdePhase2DeductionInner

Service zone

The zone named like the Sentry project's slug. If no zone has that name, one of the vault's other active zones.

sde-phase1-queue.ts · resolveSentryServiceZone

Repeats

Each Sentry issue is scored at most once per release. Repeats are suppressed for 90 days when the event carries a release, and for 7 days when it does not.

sentry/event-dedup.ts · buildIssueDeliveryId · sentry/event-dedup.ts · isDuplicate

Put the field in the title, quoted, and first.

A runtime's own error rarely names the field that went missing, so name it yourself. One helper does it for all three patterns below.

import * as Sentry from "@sentry/node"

// Sentry titles this "MissingFieldError: 'total_cents' missing
// in orders.created"; Déjà reads the field from that title.
export function reportFieldFailure(
   field: string,
   kind: "missing" | "wrong-type",
   where: string,
   extra: Record<string, unknown> = {},
): void {
   const what = kind === "missing" ? "missing" : "has the wrong type"
   const err = new Error(`'${field}' ${what} in ${where}`)
   err.name = kind === "missing" ? "MissingFieldError" : "FieldTypeError"
   Sentry.captureException(err, {
      // One Sentry issue per field, not one per line of code.
      fingerprint: ["field-failure", where, field, kind],
      extra,
   })
}

The consumer that dead-letters, and says nothing.

The handler throws, the catch moves the message to a dead-letter queue, and the only record is a log line. Sentry never hears of it, so Déjà never does — not even as a no-attribution receipt.

async function onMessage(msg: QueueMessage) {
   try {
      await handleOrder(JSON.parse(msg.body))
   } catch (err) {
      logger.warn({ err, messageId: msg.id }, "dead-lettered")
      await deadLetter.send(msg)
   }
}

async function onMessage(msg: QueueMessage) {
   try {
      await handleOrder(JSON.parse(msg.body))
   } catch (err) {
      // Before the send, so a failing DLQ cannot take the report with it.
      Sentry.captureException(err, { extra: { messageId: msg.id } })
      logger.warn({ err, messageId: msg.id }, "dead-lettered")
      await deadLetter.send(msg)
   }
}

try:
    # order["total_cents"] raises KeyError: 'total_cents'
    handle_order(json.loads(msg.body))
except Exception as err:
    sentry_sdk.capture_exception(err)
    dead_letter.send(msg)

Validation that returns a result, and nothing is thrown.

safeParse returns { success: false } instead of throwing, and the caller logs a warning and moves on. No exception, no Sentry issue.

function onOrder(payload: unknown) {
   const parsed = OrderCreated.safeParse(payload)
   if (!parsed.success) {
      logger.warn({ issues: parsed.error.issues }, "order skipped")
      return
   }
   return fulfil(parsed.data)
}

function onOrder(payload: unknown) {
   const parsed = OrderCreated.safeParse(payload)
   if (!parsed.success) {
      const issue = parsed.error.issues[0]
      const field = String(issue?.path.at(-1) ?? "payload")
      const missing =
         issue?.code === "invalid_type" && issue.received === "undefined"
      reportFieldFailure(
         field,
         missing ? "missing" : "wrong-type",
         "orders.created",
      )
      return
   }
   return fulfil(parsed.data)
}

The downstream call that is caught, and quietly logged.

A call to another service is wrapped in try/catch, the failure is logged as a warning, and the caller gets a fallback. The fallback is deliberate. The silence is not.

async function taxIdFor(invoiceId: string) {
   try {
      const invoice = await billing.getInvoice(invoiceId)
      return invoice.tax_id.trim()
   } catch (err) {
      logger.warn({ err, invoiceId }, "billing lookup failed")
      return null
   }
}

async function taxIdFor(invoiceId: string) {
   try {
      const invoice = await billing.getInvoice(invoiceId)
      if (invoice.tax_id === undefined) {
         reportFieldFailure("tax_id", "missing", "billing.getInvoice", {
            invoiceId,
         })
         return null
      }
      return invoice.tax_id.trim()
   } catch (err) {
      Sentry.captureException(err, { tags: { downstream: "billing" } })
      logger.warn({ err, invoiceId }, "billing lookup failed")
      return null
   }
}

Scored once per issue, signed either way.

Scoring

At most once per Sentry issue and release, however many events the issue collects.

Receipts

An attribution (R1) counts toward the monthly allowance, which is advisory: signing never stops. A low-confidence (R1-L) or no-attribution (R1-N) receipt never counts. See pricing.

Storage

The title becomes the incident's title in Déjà, so it should carry a field's name and never its value. What else is kept from a Sentry event is on the engine page.

Other sources

Datadog and Splunk On-Call alerts are scored too. In a Splunk On-Call alert, Déjà looks for the field in the alert's display name, entity_display_name, by the same rule. A Datadog alert cannot name the field: Déjà's intake keeps no alert title or message, so what it scores is a service check's name or a fixed label such as Datadog monitor.alert. Report a failure you want attributed to Sentry.

Visible is not attributed. Déjà attributes a failure only when a recorded change to the field it names clears the threshold — the engine publishes the rule, and the scope says what never will be. A failure that reaches scoring and does not clear the threshold still ends in a signed receipt — low confidence (R1-L) or no attribution (R1-N) — that says why.