search

jbms / beancount-import

Web UI for semi-automatically importing external data into beancount
GNU General Public License v2.0
396 stars 105 forks source link

Error handling for missing metadata fields #16

Open witten opened 5 years ago

witten commented 5 years ago

When I'm trying to import a new OFX account, and I'm in the process of setting all of the necessary Beancount-import OFX metadata in my Beancount accounts file, I'll often get errors like these when I don't yet have the metadata quite right:

 File "/usr/lib/python3.7/site-packages/beancount_import/source/ofx.py", line 529, in get_account_by_key
    raise KeyError('%s: must specify %s' % (account.account, key))
KeyError: 'Assets:MyBank: must specify capital_gains_account'
> /usr/lib/python3.7/site-packages/beancount_import/source/ofx.py(529)get_account_by_key()
-> raise KeyError('%s: must specify %s' % (account.account, key))
(Pdb)

So, getting unceremoniously dumped into a pdb shell because I'm missing a capital_gains_account entry! This is okay (but not ideal) when running Beancount-import locally in an interactive shell. It's super not great when running Beancount-import persistently on a remote web server with nothing interactive!

To be fair, I was warned of this potential issue (https://github.com/jbms/beancount-import/issues/14#issuecomment-497959182):

I think more generally some other changes may be helpful to make the beancount-import webserver more convenient as a persistent, multi-user service. For example, currently while it will reload the journal automatically there is no way to reload the import data, and failure to parse the import data often leads to terminating the program.

So I'm opening this ticket to start brainstorming solutions. The existing errors tab in the front-end seems like a nice way to present errors to the user. Would it be possible to just take the cases of errors that (currently) result in a pdb shell or exiting the program to instead manifest as recoverable errors in the UI?

jbms commented 5 years ago

Adding it as a recoverable error makes sense. For this particular error, you could substitute Expenses:FIXME or just skip the entry altogether. Another way to expose errors is to add them as a metadata field to the transaction/posting. That has the advantage of making the error more obviously associated with a particular transaction.