| Time |
Nick |
Message |
| 00:47 |
|
adam_reid joined #evergreen |
| 00:56 |
|
adam_reid joined #evergreen |
| 03:00 |
|
adam_reid joined #evergreen |
| 03:11 |
|
adam_reid joined #evergreen |
| 04:44 |
|
adam_reid joined #evergreen |
| 05:30 |
|
adam_reid joined #evergreen |
| 06:13 |
|
adam_reid joined #evergreen |
| 07:38 |
|
adam_reid joined #evergreen |
| 08:38 |
|
mmorgan joined #evergreen |
| 08:44 |
|
adam_reid joined #evergreen |
| 09:07 |
|
Dyrcona joined #evergreen |
| 09:15 |
|
adam_reid joined #evergreen |
| 10:22 |
Dyrcona |
Ugh. What's this "preinstalled server" nonsense.... ubuntu-- |
| 10:26 |
* Dyrcona |
waits for the final Ubuntu 26.04 release (supposed to happen today). |
| 10:44 |
csharp_ |
oh - interesting - Fedora 44 drops tomorrow |
| 10:45 |
csharp_ |
oh I mean that the relase party is tomorrow in advance of the release :-| |
| 11:29 |
|
adam_reid joined #evergreen |
| 12:08 |
|
jihpringle joined #evergreen |
| 12:43 |
|
jvwoolf joined #evergreen |
| 13:06 |
Dyrcona |
github-- |
| 13:06 |
Dyrcona |
I had to accept an invitation again on my laptop for it to actually take. Didn't seem to work when I did it on the phone. |
| 14:24 |
|
adam_reid joined #evergreen |
| 14:25 |
|
jihpringle joined #evergreen |
| 14:30 |
|
jihpringle joined #evergreen |
| 14:34 |
|
adam_reid joined #evergreen |
| 15:04 |
|
mmorgan joined #evergreen |
| 15:31 |
|
adam_reid joined #evergreen |
| 16:15 |
|
jihpringle joined #evergreen |
| 16:40 |
|
adam_reid joined #evergreen |
| 16:53 |
|
adam_reid joined #evergreen |
| 17:00 |
|
mmorgan left #evergreen |
| 17:02 |
gmcharlt |
Downloads page is updated with the link to the 3.15.12a tarball |
| 17:09 |
Bmagic |
gmcharlt++ |
| 17:11 |
Bmagic |
If anyone is still around: I'm trying to brainstorm ideas as to why* an item could get checked out, and the status change to Checked out, and then 1/5th of a second later, the item row is updated to "Available" again. The circulation didn't get closed, just the item status |
| 17:31 |
berick |
Bmagic: was it set to Available within the same transaction or via a separate API call? it's possible someone was editing the item (or similar) at the same time and hit Save just after the circulation, stepping on the updated status |
| 17:34 |
jeff |
what was the item status prior to being checked out? did you get unlucky in reshelving? |
| 17:35 |
jeff |
audit tables and logs are where I'd be looking. |
| 17:36 |
Bmagic |
jeff: it was Available (I thought of the reshelving race condition bug, but it was set to available many weeks prior to circ) |
| 17:37 |
Bmagic |
jeff: i'm looking at the auditor table (that's how I know it's 1/5th of a second) |
| 17:37 |
Bmagic |
berick: the auditor row responsible for making the status go back to available doesn't have a user nor workstation |
| 17:38 |
jeff |
did edit_date, editor, or status_changed_time change or precision at all during the sequence of changes? |
| 17:39 |
Bmagic |
yeah, edit_date changed.... which shouldn't change when the item only has it's status change! right? |
| 17:40 |
jeff |
presumably one of the edit_date values matches the circ xact_start. did the more recent one have millisecond precision, or is it nearest-second? |
| 17:41 |
Bmagic |
yeah, edit_date matches the previous copy of the row audit_time |
| 17:41 |
Bmagic |
exact* milisecond |
| 17:43 |
Bmagic |
am I right when I say: asset.copy edit_date is not* updated when the item is circulated? |
| 17:43 |
jeff |
typo noticed after the fact. s/change or precision/change or lose precision/ (you got the point already, I think) |
| 17:43 |
Bmagic |
because the only update to that row is the status, which affected status_changed_time, not edit_date |
| 17:44 |
jeff |
edit_date is updated on checkin/checkout (though something is about to or just recently landed that breaks the checkin part when a copy isn't circulating) |
| 17:45 |
jeff |
does audit_user or audit_ws give you any clues, or are they null on the rows you care about? |
| 17:45 |
jeff |
what version of Evergreen, by the way? |
| 17:45 |
Bmagic |
null, on the row that was recorded back to available, 3.15.5 |
| 17:46 |
Bmagic |
I have a lot of auditor rows that are to the contrary. RE: edit_date getting changed when status is the only thing changing |
| 17:46 |
jeff |
that's the row with the status being 1? |
| 17:47 |
jeff |
to the contrary of what? |
| 17:47 |
Bmagic |
contrary to what you were saying that the edit_date doesn't get updated when the status column and only the status column changes |
| 17:47 |
Bmagic |
or does* get updated rather |
| 17:47 |
jeff |
I don't think I said that. |
| 17:47 |
Bmagic |
"edit_date is updated on checkin/checkout" |
| 17:49 |
Bmagic |
so, here's the audit date for the row in the auditor table that recorded the row where status=0 "2026-04-01 09:39:10.495538-04" |
| 17:50 |
Bmagic |
which is the state of asset.copy before* it was changed at that point in time |
| 17:50 |
Bmagic |
in otherwords, that's the audit row at the moment of checkout (because the item status was 0) |
| 17:50 |
jeff |
i would expect that to match the circulation's xact_start, especially if the next audit row is status=1, which it sounds like it is. |
| 17:51 |
|
jvwoolf left #evergreen |
| 17:51 |
Bmagic |
circ xact_start is: "2026-04-01 09:39:10-04" |
| 17:52 |
Bmagic |
so, yeah, that's the circ responsible for that audit row |
| 17:52 |
Bmagic |
here's the timestamp on the very next auditor row: "2026-04-01 09:39:10.66975-04" and the status=1 for that one |
| 17:53 |
jeff |
what are the edit_date and status_changed_date values for the live row in asset.copy? are that that timestamp from the auditor row you just pasted? |
| 17:54 |
Bmagic |
and the resulting asset.copy row is status=0, I like your idea of someone editing it at the same time. The editor ID did change |
| 17:55 |
jeff |
looks like something updated the circ. do you have logs covering this time interval, or are you flying blind? |
| 17:56 |
Bmagic |
no server logs from 4/1 |
| 17:56 |
jeff |
drat. |
| 17:57 |
Bmagic |
this is a once-every-decade issue, doesn't seem to merrit the increased log collection setting |
| 17:57 |
jeff |
do the two different editor values give you enough clues to guess from or make an inquiry "hey, do you remember THREE WEEKS AGO..." (probably not worth that) :-( |
| 17:57 |
Bmagic |
I think someone was editing the item at the same time |
| 17:57 |
Bmagic |
it is odd that the save button could have been clicked 1/5th of a second after the circ, it's way to close together to think it was someone making an edit |
| 17:58 |
Bmagic |
it feels like a server-side update to the copy row at circ time |
| 17:59 |
Bmagic |
I hate to get a discussion started and the leave, but I gotta run for now. |
| 17:59 |
Bmagic |
I really appreciate the brainstorm |
| 17:59 |
Bmagic |
jeff++ berick++ |
| 17:59 |
jeff |
good luck catching it closer to when it happens next time! |
| 18:00 |
Bmagic |
I think I could come up with a clever query for the auditor table + action.circulation to discover more of these |
| 18:01 |
jeff |
or something simpler, like open circulations where target_copy status is 0? |
| 18:04 |
eby |
Schrödinger’s Copy |
| 18:10 |
Bmagic |
Yeah, that makes sense |
| 18:11 |
jeff |
was the checkout via the staff client, SIP, NCIP, other? an offline circ by any chance? |
| 18:12 |
jeff |
(usually offlines are where create_time and xact_start are different, or more than a second different) |
| 18:13 |
Bmagic |
Staff client I think |
| 18:20 |
eby |
only one in our system and it is a melcat as expected |
| 20:21 |
|
adam_reid joined #evergreen |
| 23:00 |
|
adam_reid joined #evergreen |
