One test webinar and one test registrant in the Subto Zoom account. n8n received both events and wrote nothing. It stopped at the two known problems from the Sep 28 findings, and the test exposed one new timing gap.
Update, same day: the 322a problem is resolved. The fix went live at 10:27 AM, and a real webinar went through end to end at 12:49 PM.
Times are Pacific. The test webinar was created from the Zoom web portal and scheduled for Oct 4.
| Time | Event |
|---|---|
| 9:41:04 | "Test Webinar" created in Zoom. 322a receives webinar.created and goes straight into its 5-minute wait. It doesn't reply to Zoom first. |
| 9:42:08 | Test contact registers. 323e receives the registrant (name and email, no phone), looks up the webinar in WEBINARS, finds no row, and drops it at not tracked (drop). |
| 9:46:04 | 322a resumes. The Pulse check finds no Pulse record, so it correctly decides the webinar should be added. skip mint? sends it down the "skip" output anyway, which leads nowhere. The run is marked success. |
| Step | Workflow | Result |
|---|---|---|
| Webinar created | 322a New Zoom Webinar Created | dropped Received, waited, then went down the skip branch |
| Registry write | 322d Upsert Webinar | not reached No WEBINARS row |
| Scheduling | 322b Webinar Scheduler | not reached |
| Registrant from Zoom | 323e Zoom Registrant Webhook → AC Tag | dropped Received, no matching webinar |
| Direct registrant | 323d Zoom Direct Registrant → AC Tag | no run |
| AC tag → router | 232b Lead Events in AC → Router | no run No tag was applied |
| Registration hub | 323a Webinar Registration Hub | unpublished Couldn't run either way |
| Zoom add · log | 323b · 323c | no run |
Not checked yet: what Zapier did with the same webinar and registrant.
Resolution (live 10:27 AM): Zoom now gets its reply before the 5-minute wait. skip mint? reads its check correctly, and the original Zoom data is carried through the wait. At 12:49 PM a real webinar ("Business Buying with Pace Morby", Oct 6) went into WEBINARS with its brand, registrant sheet and copy nag. The full write-up is under issue 2.
What this test showed before the fix:
The test reproduced issue 2 exactly, on the version that had been live since Sep 22. The applied changes are in Fixing 322a.
Even with a WEBINARS row and an AC tag, the registrant would stop at the hub. See issue 1 and Fixing 323a.
322a only writes the WEBINARS row after its 5-minute wait, which gives Pulse time to claim webinars it made. 323e checks for that row the moment someone registers, and drops the registrant if it isn't there yet. The test registration came 64 seconds after the webinar was created, so it was dropped. It would have been dropped even with the IF node fixed.
Real webinars rarely get registrants that quickly, but every test like this one will, and so will any webinar someone shares right after creating it.
Still open after the 322a fix: the WEBINARS row still only appears after the 5-minute wait.
Proposed fix (needs approval): when 323e finds no row, it should hold the registrant and look again after the 5-minute window, rather than dropping them. For example, it could park them in the unmatched log and retry once the webinar's row lands.
Each open step changes a production workflow or table, so each one needs Matt's approval. Webinars created before Sep 29 won't be backfilled.
ac_tag, which the hub needs in order to match.