You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems like two invoice creation attempts ran concurrently, causing duplicate invoices for some projects to be created in Quickbooks. Which projects were duplicated seems to be a function of whether the earlier creation attempt had completed for a particular project by the time the second attempt began running.
This line in InvoiceTracker.rb is intended to bail out of invoice generation if a prior QuickBooks invoice is already assigned to the invoice tracker model. However, since this association is only updated at the end of an invoicing run, it's possible for two runs to detect that no invoice exists, and then race each other for completion.
This line in Stacks::Automator intends to do the same thing (checking whether the invoice pass is marked as complete), but suffers from the same potential race condition.
We should probably have an idempotent guard / soft lock on the invoice pass model indicating whether invoice creation is in progress.
The text was updated successfully, but these errors were encountered:
It seems like two invoice creation attempts ran concurrently, causing duplicate invoices for some projects to be created in Quickbooks. Which projects were duplicated seems to be a function of whether the earlier creation attempt had completed for a particular project by the time the second attempt began running.
This line in InvoiceTracker.rb is intended to bail out of invoice generation if a prior QuickBooks invoice is already assigned to the invoice tracker model. However, since this association is only updated at the end of an invoicing run, it's possible for two runs to detect that no invoice exists, and then race each other for completion.
This line in Stacks::Automator intends to do the same thing (checking whether the invoice pass is marked as complete), but suffers from the same potential race condition.
We should probably have an idempotent guard / soft lock on the invoice pass model indicating whether invoice creation is in progress.
The text was updated successfully, but these errors were encountered: