@richardlawley would you have a quick check on this pls.
We had a user saying new bills weren't collecting data, this patch fixed it for them (existing bills were ok as data was returned from the query and used).
Fixed issue with new bills not grabbing data
Auto-Deploy finished, Test PR at http://3404.ci.librenms.org or https://3404.ci.librenms.org
I'm not sure how this could've happened. The fix hasn't rolled out to my install, and I've added a new bill without getting that error. Checking the flow through the code it doesn't look like it's possible for that value to be empty.
I can't see it causing a problem, I'm just not sure what it actually fixed!
It was a couple of weeks ago I looked at it for the chap involved but:
$period = dbFetchCell("SELECT UNIX_TIMESTAMP(CURRENT_TIMESTAMP()) - UNIX_TIMESTAMP('".mres($prev_timestamp)."')");
Would return null, so forcing a check that $period actually had data fixed it.
I realise it shouldn't need this but if there is a possibility that the $period value is not set then it stops bills so this fix just seems to safe guard things more than anything.
For that line to return null, $prev_timestamp must be null, but I cannot see a way this can happen. The only thing I can think of is that the is_null check doesn't work here, but it works fine on my system.
If you have a way to reproduce this problem, I'd be interested to see it, as it suggests there is something more complicated going on.
I don't have a way to reproduce as it works as expected for me but not someone else (Dragon2611 on IRC).
I would say this is good to merge, afaik this doesn't break things(At least not on my install)