jpwilliams / remit / 457

87%

push

travis-ci

feat(tracing): Message tracing (#66)

* 📦 Add cls-hooked@^4.2.2

* 🎉 Proof of concept

So this works, but there are a few caveats.

1. Headers overflow. If the breadcrumbs become larger than the frame size (currently 4,096 bytes) then messages fail to send. We can clip them to the last n entries that fit into the frame, but that seems a bit silly.
2. Pushing crumbs. Currently, on a request being sent and a response being received, the crumbs from the received message overwrite the current context. This is fine for single requests, but for multiple requests this creates a race condition whereby the last request to come back overwrites the status of any others. To fix this, we'd need to _merge_ statuses with the current context as they come in. For this we'd also need timestamps to decide which goes where.

#2 there is solvable, but #1 it tricker. We can't bypass headers overflowing, so ideally we'd just whack our headers into the content, but then that would break Remit v1 compatibility. A _potential_ is that we add it as a second/third option depending on where it is (data, crumbs)/(err, data, crumbs) and then Remit v1 can just ignore it, but that'd need some investigating as to whether it would work properly.

* 🐛 Only handle crumbs if crumbs are crumbs

* 🐛 Make sure arguments are padded out

Previously, if `send` was called with <2 arguments and `ns.runAndReturn` was used, namespace-related arguments would be passed in place of `data` and `opts`, causing unexpected data being transferred.

* 🔨 Start pushing originId as opposed to crumbs

* 🔥 Remove old _fingerprint

* 🐛 Fix bad trace captures

Because of CLS being introduced, the target callsite for tracing can sometimes be a bit further away.

* 🌈 Future-proof _send usage

* 🚿 Nicer ternary formatting

* 🐛 Give Emitter same send->_send treatment as Request

* 🚧 WIP

* 🌈 Finally working as designed, but needs a serious clean

* 🌈 Add new `bubble` util to handle na... (continued)

182 of 230 branches covered (79.13%)

437 of 492 relevant lines covered (88.82%)

20.5 hits per line