In the main notify routine, the before-notify composition places the
most local function (the one passed directly to notifyWith) last in the
change, after the one coming from Settings. To do otherwise could be
surprising.
Since updateEventFromWaiRequest is almost-certainly used as an argument
to notifyWith, it sets the Event Request /after/ the Settings hook has
run. Therefore, placing the header redaction as a default in Settings in
an effort to ensure it always runs was misguided: it has no effect.
This change moves the redaction into the before-notify dealing with the
WAI Request itself:
There's not (currently) any other (endorsed) way to set the Event
Request, so there's no need to redact /except/ in this function
Doing it this way should ensure we don't mess up the ordering
An Unredacted version was exported just in case that's useful
Fixes #31 for real.
NOTE: we really should have a way to put a regression test on this.
In the main notify routine, the before-notify composition places the most local function (the one passed directly to notifyWith) last in the change, after the one coming from Settings. To do otherwise could be surprising.
Since updateEventFromWaiRequest is almost-certainly used as an argument to notifyWith, it sets the Event Request /after/ the Settings hook has run. Therefore, placing the header redaction as a default in Settings in an effort to ensure it always runs was misguided: it has no effect.
This change moves the redaction into the before-notify dealing with the WAI Request itself:
Fixes #31 for real.
NOTE: we really should have a way to put a regression test on this.