This is kind of a wild one. Turns out that the triggers I was using
actually fire before the transaction is closed and I was primarily
getting lucky that the job was present on the other side of the
connection rather than having things built correctly.
I've fixed this by removing the trigger entirely and instead manually
triggering as part of the transaction. This makes the NOTIFY call happen
as soon as the transaction closes, just at the cost of making my
application be in charge of ensuring the NOTIFY gets called. Seems like
a win.
Part of doing this is porting the existing job creation code over to use
Jet. It's something I want to do anyway, so it's a win all around.
The key item here is that comms.phone and comms.email are meant to
represent a real global namespace, but comms.contact is meant to
represent an organization-specific namespace. This means the mapping,
comms.contact_phone and comms.contact_email can't key off the global
namespace. Otherwise the contact namespace would implicitly be global.
This in a pretty huge change. At a high level we're adding the concept
of a 'contact' which is a person or organization that has zero or more
contact methods (email, phone). This ended up cascading a number of
changes, including critically to the publicreprt schema. In the end it
seemed safer to get to the point where I'm confident we aren't using any
of the old fields for storing reporter information (though I haven't
deleted the columns yet) so I removed the code for defining those
columns.
At this point I think it's not possible for me to regenerate the bob
schema due to the interdependencies between my various schemas, so the
migration is well-and-truly happening.
This was an epically long change, and a terrible idea, but it compiles.
This was essentially a cascade that came about because I can't blend jet
and bob in the same transaction. In for a penny, I guess...
This is a pretty big refactor of how communication works to start moving
us in the direction we want to go long-term. This adds the new
communication row and migrates existing reports to add rows for
communication.
There's also a bunch of automatic fixes from the new linter. I should
have added them separately, but whatever.
It allows us to track when communication tasks are complete, and
information about how they were completed, separate from the entries
that created the tasks in the first place (reports, emails, texts)
This adds a bunch of stuff, including setting the organization's Lob
sender address ID, inserting mailer/compliance_report relationships,
adding external id from Lob (or maybe some other provider) and
attempting to load up the pool feature for a site.
This is a huge change. I was getting really sick of the split between
nuisance/water tables when more than half of the data they store is
common. I finally bit off the big work of switching it all.
This creates a single unified table, publicreport.report and copies the
existing report data into it. It also ports existing data from the
original tables into the new table.
Along with all of this I also overhauled the system for handling
asynchronous work to use a LISTEN/NOTIFY connection from the database
and a single cache table to avoid ever losing work.
This refactor was born out of the inter-dependency cycles developing
between the "background" module and just about every other module which
was caused by the background module becoming a dependency of every
module that needed to background work and the fact that the background
module was also supposedly responsible for the logic for processing
those tasks.
Instead the "background" module is now very, very shallow and relies
entirely on the Postgres NOTIFY logic for triggering jobs. There's a new
table, `job` which holds just a type and single row ID.
All told, this means that jobs can be added to the queue as part of the
API-level or platform-level transaction, ensuring atomicity, and
processing coordination is handled by the platform module, which can
depend on anything.
This involves rebuilding the "publicreport.report_location" view after
making a bunch of changes to making publicreport.water the consistent
name (over pool) throughout RMA tables.
