Session status handler bugs
Closed this issue · 2 comments
Certain status changes work fine, others are firing change events to the handler classes but then the handler class does a bunch of wonky stuff looking for the 'after' status and the run method will break.
SessionStatusHandler and its endpoint onSessionUpdate have been changed a bit to cut down on the amount of unused data being passed to the handler with the 'change' object:
so that SessionStatusHandler only takes change.after converted to a sessionDBC...
The problems arise when 'published' moves to 'active'. For some reason, while this methodology for executing onUpdate functions targeting a status works fine on 'potential' -> 'published' (slots creation), as well as on 'published' -> 'full' (non-mf, so making sure no task schedules). But when you do 'published' to 'active', the handler sees the data it's passed, but doesn't act on it, almost as if there were no case written to handle that case.
Next order of action is to go around this one, and see if it's the only one that behaves this way, or if it has something in common with another one that turns out to do the same thing. I'm a bit skeptical right now of the Notification class as it hasn't been stepped thru to make sure that nothing weird is happening in imports/constructors/idk what else.
From there we should continue writing around it.
Running tsc threw two errors. One of them is NotificationDBC.spec.ts in which the dbc still takes six arguments, indicating that the test hasn't been run on the new class, so task now is to step through that and make sure it works as expected.
ALSO maybe it's necessary to be running tsc between changes to the functions and running the emulator. Where else would the changes be compiled? IDK. Maybe because there's a predeploy hook in firebase.json? but i dont see this being run anywhere. This would explain why the breakpoints dont work at all now
SO THE PROBLEM WAS....
It looks like tsc doesn't run the predeploy hook between cold starts. This means you have to re-transpile the code every time you want to start the emulators...so either I'm wrong and it does run tsc, but was being blocked by those two errors, OR we just have to make a script to clean it up which would have been done anyway
Unfortunately there's no way to know until I make changes to the slot handler and test it because....after fixing the two errors, i went ahead and ran tsc myself before trying the emus again, making it unclear what actually fixed it