Running background services

Since the last 2 updates (I don’t know which one), my background services quit running. I’ve been debugging this all day and what I found doesn’t make sense. I’m in the file “execute_background_services.php” and it appears every time it goes to generic_sql_affected_rows() it always returns -1 and breaks the loop. my service never gets ran.

I feel like I’m doing something wrong because… well… everyone should be having troubles not just me.


I wanted to add a screen shot of the code I’m working with. Thought it would help people to see where I think it’s breaking. In this case line 140 seems to always be -1.

I’d be willing to be it is the query above that. According to that query it should set your running flag to 1 and if not then that is what is breaking. I wonder if the comparisons being used are breaking there if the last year it was used is more than 1 year prior or something weird like that (i noted on all the demos that have the uuid service from 6.0 to dev are not working, so am guessing bug became unmasked when maybe hit year 2023; i am just guessing at this point though).

The query above is setting the flag to 1 and next_run is being updated too. Afterwards it’s always -1. I can’t step through like I would with Visual Studio, but I have enough error_logs in there I’m getting a pretty good idea. I wonder if something changed in the latest PHP… it never hits my error_log in line 134.

1 Like

Looks like uuid service is working in the 7.0.0.2 demos (the main production demos), but seems to hang in the 7.0.1-dev demos (like you are stating with your service where it gets stuck in running mode and next_run is set).

1 Like

@brad ,
Try this fix:

1 Like

Thanks for this, I will change it in my system and will report back!

This is the weirdest thing. I am not finding sql.inc.php in my library directory.
Here is an image of the files in my library directory:

???

hi @gutiersa ,
No need to fix this in 7.0.0 (it works fine) which has sql.inc instead of sql.inc.php. This was only broken in the development codebase (ie. master branch ).

1 Like

she was the one that alerted me to it. Her system had been sending claims without issue for awhile, then updated something and it stopped working. That’s when I started trying to get the last docker and found this problem.

I’m working on a few updates to the module to give easier visibility to the messages in x12_tracker and I think I’m going to have an option to disable(ish) the sftp send service. New tab in the module will add an check the background services to make sure the ones I use are setup, show next run time, etc. also I think it’ll recommend to change sftp next run to some far future date and disable the service. I worry it may get undone everytime someone does a save in the config screen though. Maybe giving it another class to call could be a more permanent solution. A class that just returns and doesn’t do anything. Then an option to enable and put it back the way it was if they need to.

My first guess was there was a race condition where the sftp send saw the record, and couldn’t find ftp info and then errored it out. For that reason there is now a tab to see records in the x12 tracker.
I considered (and tested today) putting bad data in the ftp properties in x12 partners. I’m not sure if that worked or not. But I saw errors in php logs, so I didn’t like it. Claims were sent, but I don’t know if my service just got there first.

I think it does seem to be working fine on another clients setup, but he’s getting sftp errors. says he’s fine with it but again I feel like it may not work one day; and be totally random.

I’m rambling, but the fix I’m thinking as I type this (talking it through) is to go with putting periods in the sftp related properties in x12 partners, then having the module replace the class the sftp calls to a class that doesn’t do anything. That would stop the php errors and stop the errors being displayed to the user.

Now as to why it’s not working for @gutiersa ; I’m wondering if it’s PHP related and not core code related. @gutiersa Did you upgrade your system to a higher level of PHP? My developer gut tells me it’s a PHP thing. Code that’s been working for so long just doesn’t stop working unless there is a larger outside influence.

Anyhow, I hope to have the module updated and ready to go soon. I was working on your code review tasks and trying to figure out the background service at the same time.

2 Likes

My system is php 8.1