| Time |
Nick |
Message |
| 07:01 |
|
JBoyer joined #evergreen |
| 07:10 |
|
rjackson_isl joined #evergreen |
| 07:15 |
|
agoben joined #evergreen |
| 07:30 |
|
bdljohn joined #evergreen |
| 07:56 |
|
_bott_ joined #evergreen |
| 08:21 |
|
bos20k joined #evergreen |
| 08:23 |
pinesol |
[evergreen|Cesar Velez] LP1765179 - fix issue with pending/staged user reg - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=58d7812> |
| 08:41 |
|
mmorgan joined #evergreen |
| 08:53 |
|
tlittle joined #evergreen |
| 08:59 |
|
jvwoolf joined #evergreen |
| 08:59 |
|
Dyrcona joined #evergreen |
| 09:14 |
mmorgan |
@later tell krvmga Have a look at bug 1657171 |
| 09:14 |
pinesol |
mmorgan: The operation succeeded. |
| 09:21 |
|
stephengwills joined #evergreen |
| 09:44 |
csharp |
pinesol: ahem bug 1657171 |
| 09:45 |
pinesol |
csharp: Yeah, well, you know, that's just like uh, your opinion, man. |
| 09:45 |
pinesol |
Launchpad bug 1657171 in Evergreen master "ASCII apostrophe and Unicode right single quotation mark should be normalized" [Medium,Confirmed] https://launchpad.net/bugs/1657171 |
| 10:09 |
|
dkyle1 joined #evergreen |
| 10:12 |
|
dbwells joined #evergreen |
| 10:24 |
rhamby |
csharp: fyi my messages are bouncing from the outreach list due to combined.njabl.org blocking but that database is inactive I believe |
| 10:24 |
JBoyer |
csharp, are you an admin on lists.evergreen-ils.org? I just had a message bounced because of combined.njabl. org which was discontinued in 2013 and is now apparently a porn redirect. |
| 10:25 |
rhamby |
what Jboyer said :) |
| 10:25 |
* JBoyer |
guesses it just started today |
| 10:25 |
JBoyer |
:) |
| 10:28 |
csharp |
ugh - I'll look into it :-/ |
| 10:29 |
rhamby |
csharp: happy new years! :) |
| 10:29 |
csharp |
is it just the outreach list? |
| 10:29 |
csharp |
rhamby: you too :-D |
| 10:30 |
* csharp |
transfers his case of the Mondays to Wednesday |
| 10:33 |
|
aabbee joined #evergreen |
| 10:42 |
csharp |
okay, I think it's fixed |
| 10:42 |
csharp |
please try sending again |
| 10:46 |
|
khuckins joined #evergreen |
| 11:16 |
|
Bmagic joined #evergreen |
| 11:16 |
Bmagic |
@coffee [someone] |
| 11:16 |
* pinesol |
brews and pours a cup of Stars of Italy Espresso, and sends it sliding down the bar to jyorio |
| 11:17 |
JBoyer |
csharp++ |
| 11:17 |
JBoyer |
terran++ |
| 11:33 |
|
Christineb joined #evergreen |
| 12:05 |
|
jihpringle joined #evergreen |
| 12:06 |
|
beanjammin joined #evergreen |
| 12:35 |
Bmagic |
Anyone have any theories as to why the EDI invoice message is processed successfully but does not create an invoice in the database? |
| 12:44 |
Bmagic |
I guess the reason could be that the PO is canceled? |
| 12:48 |
Bmagic |
wait, the PO isn't but the lineitems are (backordered) and keep_debits = true for that cancel reason. That sounds normal to me. |
| 12:51 |
Bmagic |
I trapped a log line claiming that the edi_fetcher created an acq.invoice_entry with an identity 289351 (which I presume is the sequence ID number). The database does not have a row with that ID..... |
| 12:55 |
Dyrcona |
Well, I was just looking into another case of a PO doesn't create an order because the A/T runner dies while processing the PO JEDI event. |
| 12:56 |
Bmagic |
I manually ran the fetcher in this case, it looked like it exited normally |
| 12:56 |
Dyrcona |
I think we might need an index on acq.lineitem, but I have too much else going on right now to look into it today. |
| 12:56 |
Dyrcona |
Did you see lines like this: Use of uninitialized value in string ne at /usr/local/share/perl/5.22.1/OpenILS/Application/Acq/EDI.pm line 543. |
| 12:57 |
* csharp |
is paying attention to this discussion, but doesn't have any theories |
| 12:57 |
Bmagic |
It's so odd to see the log line plain as day claiming that it received a new db row: |
| 12:57 |
Bmagic |
editor[1|0] request en-US open-ils.cstore.direct.acq.invoice_entry.create <new object> |
| 12:57 |
Bmagic |
editor[1|0] created a new acq.invoice_entry object with Identity 289351 |
| 12:57 |
Dyrcona |
I was going to ask csharp if he had seen this sort of thing before. |
| 12:58 |
csharp |
I've seen similar issues, but not this specifically |
| 12:58 |
Bmagic |
Dyrcona: I do not have that error |
| 12:58 |
Dyrcona |
Well, I think Bmagic and I are speaking about different issues. I don't recall seeing Bmagic's issue either, but that doesn't mean that I haven't. |
| 12:59 |
Dyrcona |
Bmagic: OK. We get that one a lot from the fetcher. Seems not everyone enters the vendcode where they should. :) |
| 12:59 |
Bmagic |
select * from acq.invoice_entry where id=289351; (0 rows) |
| 12:59 |
Dyrcona |
Bmagic: Either the code failed to commit, or died before the transaction commit statement. |
| 13:00 |
Dyrcona |
You will get an ID in the middle of a transaction, but if the commit doesn't happen, the row does not end up in the database. |
| 13:00 |
Bmagic |
hmmm, vendcode |
| 13:00 |
Dyrcona |
I know that's not very helpful, but that's the best I've got right now. |
| 13:01 |
Bmagic |
yeah, it must be a transaction |
| 13:01 |
Bmagic |
uncommitted |
| 13:02 |
Dyrcona |
Maybe there was a Lp bug for that? It seems to ring a bell, though rather faintly. |
| 13:02 |
Bmagic |
the other clue is that there aren't any rows in acq.invoice either |
| 13:03 |
csharp |
must be choking somewhere and it dies before it can log what's wrong (which is the worst) |
| 13:03 |
Dyrcona |
There might be something in the database logs. |
| 13:03 |
Bmagic |
oooo, I bet it's that darn deleted bib issue again. let me run some queries |
| 13:03 |
Bmagic |
I checked the postgres logs, no related errors |
| 13:03 |
csharp |
yeah - that's what I was connecting it to as well |
| 13:04 |
Bmagic |
following the osrfsys.log, it proceeds to lookup all of the related lineitems.... |
| 13:06 |
Bmagic |
darn, they are all non-deleted |
| 13:07 |
Dyrcona |
How many lineitems? |
| 13:07 |
Bmagic |
4 |
| 13:07 |
Bmagic |
(related to this invoice) |
| 13:07 |
Dyrcona |
OK. So not likely timing out getting the data. |
| 13:08 |
Dyrcona |
My process just dies and there's a message about cstore not getting any data, so it looks like a timeout. |
| 13:08 |
Bmagic |
it looks like it's dealing with each one, one at a time |
| 13:09 |
Bmagic |
ah! editor[1|0] rolling back db session |
| 13:09 |
Bmagic |
it rolled it back just after receiving the results from open-ils.cstore.direct.acq.fund_debit.search.atomic {"id":[1870282]} |
| 13:11 |
Bmagic |
that row exists... encumbrance = true, debit_type=purchase, invoice_entry=null |
| 13:16 |
Dyrcona |
Dunno 'bout that one. |
| 13:16 |
Bmagic |
edi_fetcher.pl is short and sweet, the logic to rollback must be in Application::Acq::EDI->process_retrieval() |
| 13:20 |
Dyrcona |
Yes, I would think most of the code is there. |
| 13:37 |
|
bdljohn1 joined #evergreen |
| 14:00 |
Dyrcona |
Bmagic: Are you getting anywhere? |
| 14:00 |
Bmagic |
not really. but I have developed some ideas |
| 14:01 |
Bmagic |
I am about to give up and tell the vendor and library to make a new PO |
| 14:01 |
Bmagic |
(this one is from August) |
| 14:01 |
Bmagic |
I did find a line that might be responsible for silently dying |
| 14:02 |
Bmagic |
if ($orig_entry->amount_paid != $entry->amount_paid or $entry->phys_item_count != $orig_entry->phys_item_count) |
| 14:02 |
Bmagic |
seems that if those are not equal it could fail without log |
| 14:03 |
Dyrcona |
Is either of those the case in your current situation? |
| 14:04 |
Bmagic |
I'm not really sure how to compare apples to apples |
| 14:04 |
Bmagic |
There doesn't seem to be a column for phys_item_count |
| 14:05 |
Dyrcona |
OK. I figured one is calculated from the database and the other comes from the invoice, and EDI is difficult to decipher. |
| 14:05 |
Bmagic |
I am having a memory of something like "keep debits" needs to be off/on for PO's that contain line items that are not for items (like shipping or tax) |
| 14:07 |
|
hbrennan joined #evergreen |
| 14:08 |
Dyrcona |
Bmagic: Could be. |
| 14:29 |
|
khuckins_ joined #evergreen |
| 15:49 |
|
dkyle1 joined #evergreen |
| 15:54 |
Bmagic |
Anyone else having "available items" showing as in-transit? That is to say asset.copy.status=0 but there is an unfinished row in action.transit_copy for the exact copy |
| 15:54 |
Dyrcona |
Bmagic: Yes, all the time, I believe there have been some recent bug fixes to prevent that in the future. |
| 15:55 |
Bmagic |
I am about to conclude that it's due to reshelving status copies going into transit, within the same time frame as the reshelving coming behind and setting the status=0 |
| 15:55 |
Bmagic |
oh! dang, I missed the memo on that |
| 15:55 |
|
khuckins joined #evergreen |
| 15:56 |
Dyrcona |
Well, there have been some fixes related to transits and statuses, but maybe not your specific issue. |
| 15:56 |
Dyrcona |
Bmagic: Are you running 3.2, yet? |
| 15:56 |
Bmagic |
not in production |
| 15:56 |
Bmagic |
Everyone is scared to let go of XUL |
| 15:57 |
Dyrcona |
XUL is still there, but copy alerts will be busted. |
| 15:57 |
Bmagic |
they are already busted in 3.1.x if I'm not mistaken |
| 15:57 |
Dyrcona |
Oh, right. We're on 3.0 and plan to skip 3.1. |
| 15:57 |
Bmagic |
but you're going to compile xul in 3.2? |
| 15:58 |
Dyrcona |
I might, yeah. |
| 15:58 |
Bmagic |
I was leaning that way as well, but we didn't want to do something that was "unsupported" |
| 15:58 |
Dyrcona |
:) |
| 15:58 |
Bmagic |
then get stuck with tickets for XUL that would end up with "sorry, you need to use Webby" |
| 15:59 |
jihpringle |
Bmagic: LP 1787274 |
| 15:59 |
pinesol |
Launchpad bug 1787274 in Evergreen 3.1 "Web Client: Transits Don't Always Clear" [Critical,Fix released] https://launchpad.net/bugs/1787274 |
| 15:59 |
Dyrcona |
XUL itself is unsupported. |
| 15:59 |
Dyrcona |
jihpringle++ |
| 15:59 |
Bmagic |
jihpringle: Ha, I was just reading that bug |
| 15:59 |
* Dyrcona |
was about to look for that. |
| 16:00 |
jihpringle |
we've stopped getting reports of it since we went from 3.1.2 to 3.1.7 |
| 16:00 |
jihpringle |
we also cleaned up the existing ones after we went to 3.1.7 |
| 16:00 |
Bmagic |
I'll betcha that is what is going on here |
| 16:00 |
Bmagic |
I figured it was the reshelver... but it might be duplicate rows |
| 16:01 |
Dyrcona |
Hm.... Something in storage actually generates this query: SELECT id FROM action.circulation WHERE stop_fines IS NULL AND recurring_fine <> 0 AND max_fine <> 0 ? |
| 16:01 |
jihpringle |
Bmagic before the fix we were getting reports from libraries of items that were available and in transit at the same time so it sounds like what you're seeing |
| 16:01 |
Dyrcona |
Must be the fine generator... |
| 16:02 |
Bmagic |
yeah, that's it |
| 16:02 |
Bmagic |
(jihpringle) not Dyrcona |
| 16:02 |
Dyrcona |
Yeah, I gathered. ;) |
| 16:02 |
Dyrcona |
Yeah, that's probably your issue. |
| 16:02 |
Bmagic |
Dyrcona++ |
| 16:02 |
Bmagic |
jihpringle++ |
| 16:03 |
Bmagic |
anyone know if pinesol counts the ++ if there are multiples in the same message? |
| 16:03 |
Dyrcona |
I believe so. |
| 16:03 |
Bmagic |
@karma jihpringle |
| 16:03 |
pinesol |
Bmagic: Karma for "jihpringle" has been increased 17 times and decreased 0 times for a total karma of 17. |
| 16:03 |
Dyrcona |
Bmagic++ jihpringle++ |
| 16:03 |
Bmagic |
Dyrcona++ jihpringle++ |
| 16:03 |
Bmagic |
@karma jihpringle |
| 16:03 |
pinesol |
Bmagic: Karma for "jihpringle" has been increased 19 times and decreased 0 times for a total karma of 19. |
| 16:03 |
Bmagic |
ha |
| 16:03 |
Bmagic |
shonuff |
| 16:16 |
|
dkyle1 joined #evergreen |
| 17:05 |
|
mmorgan left #evergreen |
| 17:35 |
|
dkyle1 joined #evergreen |
| 18:06 |
|
khuckins joined #evergreen |
| 18:16 |
|
nondredfru joined #evergreen |
| 19:37 |
|
beanjammin joined #evergreen |
| 21:27 |
|
sandbergja joined #evergreen |
