Hello @anvil I really need your help to sort this out.
This is happening way too often since mid-march.
Before mid-march, I’ve never experienced this specific error:
anvil.tables.TableError: Internal database error: ERROR: canceling statement due to user request
Here’s the full list of logs available to me filtered by “Errors only”:
Date - Session ID - Error
17/02/2022 - LGS74INYPUYY53AWEAXOC7VLUPD2A7C7 - anvil.server.UplinkDisconnectedError: Uplink disconnected
16/03/2022 - C3YJUWPFSOCWPR4NM26S7KRDENYRAU4G - anvil.server.UplinkDisconnectedError: Uplink disconnected
16/03/2022 - NSOMZMPRYS3IHNU3IOJKIRTRJ5W3H5XX - anvil.server.UplinkDisconnectedError: Uplink disconnected
24/03/2022 - VQPRBSD2SPJCXXSWJJ27NDQKEVR2MPGO - anvil.tables.TableError: Internal database error: ERROR: canceling statement due to user request
04/04/2022 - CXZIBQGOXELU7QQXOCWU5PK2QUHYRNCB - anvil.tables.TableError: Internal database error: ERROR: canceling statement due to user request
11/04/2022 - N7PGDX3SDPCZPZ7FS77D3R3UY6SOLNQ5 - anvil.tables.TableError: Internal database error: ERROR: canceling statement due to user request
12/04/2022 - CZ3HVG2XGGQSZKLBJPIOXDVZVKWGQATZ - anvil.tables.TableError: Internal database error: ERROR: canceling statement due to user request
17/04/2022 - VIP3VCT6ZOPJPNBQXUNBDMNZE6S2AM4N - anvil.tables.TableError: Internal database error: ERROR: canceling statement due to user request
19/04/2022 - KVQ5PX3ADFVBNOC2IX25YDJ7PEHTAOYU - anvil.tables.TableError: Internal database error: ERROR: canceling statement due to user request
19/04/2022 - S76WCYCN37DLRE3RH7BEDB4TI6IVZTK6 - anvil.tables.TableError: Internal database error: ERROR: canceling statement due to user request
You see how this is a constant and frequent error since march the 24th.
This is a background task failing (named sentinella, in case you want to check logs).
It starts at 03.00 am.
Usually when I re-start it in the morning after a failure, it is able to complete. But not today. The second fail on 19/04 is this morning’s run.
From Anvil’s session-error log I see the error is given by the code line in my first post.
That is a statement inside the function:
def log_db(level, messaggio):
now = datetime.now()
msg_str = str(messaggio)
if logging_levels[level] <= logging_levels[logging_level]:
app_tables.log_rows.add_row(execution_log_uuid=task_uuid,
timestamp=now,
level=level,
text=msg_str)
Looking at my application log I see it was inside this loop when the log_db statement failed:
def get_eids_documenti_archiviati():
log_db('info', 'get_eids_documenti_archiviati - enter')
log_db('info', ' getting documents in database for campaign "{campagna}"'.format(campagna=campagna))
campagna_row = app_tables.configurazione.get(campagna=campagna)
archiviati = app_tables.documenti.search(q.all_of(campagna=campagna_row, envelope_id=q.not_('')))
archived_ids = {}
for doc_archiviato in archiviati:
log_db('info', ' getting archived IDs for envelope {eid}'.format(eid=doc_archiviato['envelope_id'])) # --> THIS IS THE STATEMENT GENERATING THE ERROR
archived_ids[doc_archiviato['envelope_id']] = {
'id_pdv_documento': doc_archiviato['id_pdv_documento'],
'id_pdv_audittrail': doc_archiviato['id_pdv_audittrail']
}
log_db('debug', repr(archived_ids))
log_db('info', 'get_eids_documenti_archiviati - exit')
return archived_ids
My application log looks indeed like:
...
2022-04-19 07:01:10.319712+00:00 - info - getting archived IDs for envelope 91625d8a-4b70-4d20-b9dc-bb84ecd65eb0
2022-04-19 07:01:10.330127+00:00 - info - getting archived IDs for envelope e8404bdb-5225-4895-bd0a-c3dc775bd361
2022-04-19 07:01:10.342542+00:00 - info - getting archived IDs for envelope a4f88ff4-f1c6-4f3b-b986-064a2a2dcc43
2022-04-19 07:01:10.354813+00:00 - info - getting archived IDs for envelope ff1ec906-dec3-43b4-ace5-1c5dffa177ef
2022-04-19 07:01:10.369307+00:00 - info - getting archived IDs for envelope 0a93c551-aac4-4939-b22d-20cf4e421fda
2022-04-19 07:01:11.075294+00:00 - info - getting archived IDs for envelope 3aa26672-1259-4693-bffa-356e27231bc4
...
As already said, the log_rows table is usually empty. During the task execution it is filled, then at the end the log is dumped to a text file, then zipped and archived as media object in another table, then the log_rows table is emptied.
I can’t figure out
- why this should not work
- why this stopped working suddenly. Something happened on DB side?
- if I could do that in some other way, given that logging on temporary files does not guarantee that the log will still be there when I need it. May be I could simply
print things out but logging to a table allowed me to give admin user access to logs at an application level.
Again, sorry to address this to @anvil directly, I don’t know if this fits more the forums or the support channel.
Let me know if I should send an email to support for this.
Thanks and BR
