npub18369m6ejyjfh47ths7qrlvqcu8jvyzxnuysx72cpvg95jfvt9l0s5z8jp6 (npub1836…8jp6) I spent 2-3 hours this week trying to diagnose a bug in my data upgrader. I had some SQL statements that would create a new table, copy the data from the old one, delete the old one, and rename the new one -- basically just changing some columns in an awkward way, for reasons.
It was saying that it couldn't find one of the existing columns in the old table when doing the copy. But every time I put in a breakpoint and inspected the DB directly... the column was there! And when I added logging statements, the column was missing!
Are you ready for this?
I had written this code a while back, and I had forgotten that this large method had a dry-run parameter. It would get run *twice*, first as a dry-run with transactions rolled back, then for real. But I had forgotten to add the rollback for this transaction, so on the second run it would be working with the actually-changed data, and of course nothing made sense.
The breakpoint would always activate on the *first* run, so I never saw the bug when debugging. And I only saw the logging statements from the second run because they were so voluminous. 😩
Yes, I was very clever to write my code this way. -.-
varx/tech /
npub13c…u3sx0
2023-11-23 17:00:52
in reply to nevent1q…4223
Author Public Key
npub13cavz8sul0get8lllzwszm7j5mq4n3ygpn60uqn54su99csl9wyqeu3sx0Published at
2023-11-23 17:00:52Event JSON
{
"id": "6f6429ac375a13611861b4c8766f92c09f08d1f66ee3c092608df4984eed5bcf",
"pubkey": "8e3ac11e1cfbd1959ffff89d016fd2a6c159c4880cf4fe0274ac3852e21f2b88",
"created_at": 1700758852,
"kind": 1,
"tags": [
[
"p",
"3c745deb3224937af97787803fb018e1e4c208d3e1206f2b01620b49258b2fdf",
"wss://relay.mostr.pub"
],
[
"p",
"4b06a99655066ca3e1a19ecc4bd5c5fd5d0f106a319a8cfb3c414bdff9e17c27",
"wss://relay.mostr.pub"
],
[
"e",
"6989b63ab57104369cd4f015fb6071d587caa8d4efca185efab0fb84bb33d1a2",
"wss://relay.mostr.pub",
"reply"
],
[
"proxy",
"https://infosec.exchange/users/varx/statuses/111460932147230846",
"activitypub"
]
],
"content": "nostr:npub18369m6ejyjfh47ths7qrlvqcu8jvyzxnuysx72cpvg95jfvt9l0s5z8jp6 I spent 2-3 hours this week trying to diagnose a bug in my data upgrader. I had some SQL statements that would create a new table, copy the data from the old one, delete the old one, and rename the new one -- basically just changing some columns in an awkward way, for reasons.\n\nIt was saying that it couldn't find one of the existing columns in the old table when doing the copy. But every time I put in a breakpoint and inspected the DB directly... the column was there! And when I added logging statements, the column was missing!\n\nAre you ready for this?\n\nI had written this code a while back, and I had forgotten that this large method had a dry-run parameter. It would get run *twice*, first as a dry-run with transactions rolled back, then for real. But I had forgotten to add the rollback for this transaction, so on the second run it would be working with the actually-changed data, and of course nothing made sense.\n\nThe breakpoint would always activate on the *first* run, so I never saw the bug when debugging. And I only saw the logging statements from the second run because they were so voluminous. 😩 \n\nYes, I was very clever to write my code this way. -.-",
"sig": "2ff47f41d00dac4808c6179e1fd90be26eb6e6e99e714c152c954fb7fe2dc22fc8c548e052618a7c34949a3623511d32ebf2008a254d5be46a02ba41950ed151"
}