this should only affect "secondary" threads for use with real-time
sync to farmOS. the belief is that when a token refresh happens in
main thread, the session is auto-saved with the new token. but when a
token refresh happens in secondary thread, the session was not being
auto-saved with new token. so this should fix that...
in some cases (maybe just dev?) the record does not exist in farmOS;
if so we should silently ignore.
and there seemed to be a problem with the sequence of events:
- user clicks delete in WF
- record is deleted from WF DB
- delete request sent to farmOS API
- webhook on farmOS side calls back to WF webhook URI
somewhere in there, in practice things seemed to hang after user
clicks delete. i suppose the thread handling user's request is "tied
up" somehow, such that the webhook receiver can't process that
request? that doesn't exactly make sense to me, but if we split off
to a separate thread to request the farmOS deletion, things seem to
work okay. so maybe that idea is more accurate than i'd expect
this is just to get our foot in the door so to speak. not sure yet
how sophisticated this map needs to be etc. but thought it would be
nice to at least show something..since the data is available
this lets farmOS send a POST request to a webhook URL in our app,
which then records a "stub" record in a change queue table. from
there a daemon should process the queue and import/delete records as
needed in our app DB.
this all requires setup on the farmOS side as well..those details will
be documented elsewhere (eventually!)
not sure if this is a unique situation in my dev environment or
what..but i keep encountering this in dev, so might as well add it.
better safe than sorry
