Evergreen ILS Website

IRC log for #evergreen, 2019-01-02

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

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/O​penILS/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

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat