Shipmind Labs

Someone forwarded us a link that "did nothing". We had logging around every link we routed, so we went looking for it, and found nothing at all. No acceptance, no refusal. Silence.

The link had been sent twice. The second copy landed inside our dedupe window and returned early, before any call-site logging ran. The one decision we most needed to see was the only one we never wrote down.

A week later, the opposite failure. Our reporting hook threw on a payload it did not expect, inside a Linking handler. A link that anyone on the internet can send turned into a crash in the app.

Both of those shaped how auditing works in deeplinkmap, our open-source deep link router.

One hook, configured on the router, not at each call site. Call sites forget. Constructors do not.

The decision comes first, the event second. Resolution is reached internally, stamped with the router's own clock, and only then handed to the hook. Routing does not depend on the logger.

The report call is wrapped and swallows anything the hook throws. If reporting fails, the event is lost and the link still opens. That trade is deliberate (we would rather lose a log line than crash on untrusted input).

Drops are events too. The intake layer reads the router's hook once when it is built, so a link dropped as a repeat is reported with the source it arrived through, cold start or warm resume, and lands in the same log as the accepted and refused ones.

And that source is recorded, not routed on. The moment delivery channel starts changing behaviour, you have two products to support instead of one.

With no hook configured, nothing is reported at all. That part should probably be a choice, not a default someone discovers during an incident.

Worth knowing where your own dropped requests end up, in the same log as the handled ones, or nowhere.

Was this useful?

Building something similar?

or email hello@shipmindlabs.com