← deemwar engineering examples Runnable · Node · zero deps · free

It looks like your payload. It's actually your account.

A send starts failing — or an account gets restricted — right after some unrelated-looking change: a new link format, a longer message, an emoji. The natural hypothesis is "my payload triggered this." Often it's account-class policy instead: many platforms enforce more strictly on new or low-reputation accounts, and the rejection reads identically to a payload problem from the client side.

The crux

function serverPolicy(accountClass, payload) {
  if (accountClass === 'new' && payload.hasLink) {
    return { accepted: false, reason: 'policy: unverified accounts cannot send links' };
  }
  return { accepted: true, reason: null };
}

Nothing in that function reads the payload's format — only whether it has a link, and the account's class. Reformatting the link, wrapping it differently, changing the message length — none of it touches the variable that actually decides the outcome. The only way to tell a payload bug from an account-class policy is a controlled experiment: hold the payload fixed, vary the account.

Run it

node check.js --demo

Zero dependencies, no network — runs the wrong experiment first (three payload reformats, same account, all rejected), then the right one (one unmodified payload, two account classes).

$ node check.js --demo Hypothesis A: "it is something about how the link is formatted." variant 1 (new account): accepted=false variant 2 (new account): accepted=false variant 3 (new account): accepted=false Every payload variant was rejected on the same account. Payload was never the variable. Now hold the ORIGINAL payload fixed and vary the account instead: new account, same payload -> accepted=false (policy: unverified accounts cannot send links) established account, same payload -> accepted=true (ok) DIAGNOSIS: the identical, unmodified payload succeeds from one account and fails from another. The discriminating variable was account class the whole time -- every hour spent reformatting the payload was testing the wrong axis.

The fix

Run the control experiment before the payload experiment. Hold the message fixed and vary the account (age, verification state, sending history) before touching a single character of the payload.
Don't trust a generic rejection message to tell you the cause. "Rejected" and "policy-restricted" often look identical from the client side.
Log account class alongside every send outcome if you operate multiple accounts — without it you can't retroactively tell whether a cluster of failures shares an account trait.

Check your own incident

When this started, did it correlate with a payload change — or with an account trait?
Have you actually run the payload unmodified from a different account and gotten a different result? If not, the client-bug hypothesis is unfalsified, not confirmed.
Does your monitoring distinguish "this account is restricted" from "this specific send was malformed"?

Get the code

Source on GitHub