BusinessTime::addBusinessHours can lead to infinite loops
garimpeirodouniverso opened this issue · comments
Depending on the Constraints set for a given BusinessTime, e.g: if there are no Business Hours defined after a given time, and we try to add Business Hours after said time, then BusinessTime::addBusinessHours will enter an infinite loop (as it will never reach a isBusinessTime() date anymore).
On an environment where the Constraints are defined by user input, this might happen at some point.
Of course we could validate the Constraints when building the BusinessTime definition and check if there is at least one "recurrent" Business Time defined for it, but another solution is to have a threshold of iterations inside some loops of this class.
Does that make sense to you guys?
(PS: library is awesome!! Thanks for all the effort)
@garimpeirodouniverso Good point. Currently it's just been implemented with the assumption that client code has to be careful with defining constraints, i.e. avoid infinite periods of no business time.
We could put a trivial iteration limit on and throw an exception there to make it clear?
@hughgrigg I guess that will suffice. At least this is the approach I am following right now (had to overwrite this method locally to limit the loop iteration).
@garimpeirodouniverso I'm curious about the situation where you have a cut-off with no business time after it ever again. If that is the case, it seems like you want a "never" result after a cut-off, which could be done with Carbon::isAfter() alone.
@hughgrigg actually all the information about business/non-business time is provided by the end-user, which will manipulate something like a "calendar" model and save it to a database. So, as absurd as the idea of having a cut-off with no business time after it ever again sounds, it could happen (as it is user provided in my case).
We can have "warnings" to indicate that a calendar has no consistent business times, but I found it safer to avoid these infinites inside the code as well.
Also, as the library does not restrict such business times compositions (and IMO it shouldn't restrict), having this limit would be interesting for an unaware developer :P (or at least a very clear warning of such scenario)
@garimpeirodouniverso Ah yes, user input does make this quite easy to occur. I wonder if a dedicated validateConstraintsTerminate method would help? That could be called when the user inputs them to give immediate feedback. Just wondering about the best way to implement it though.
@hughgrigg I guess a validation method would be welcome. Maybe something in the lines of validating whether the combination of constraints of a BusinessTime/BusinessTimeFactory is "finite" or not, idk.
Are you planning on doing this AND the limitation of iterations? I still like the idea of having the library being infinite-loops bullet-proof... But I guess that is up to you guys :P
@garimpeirodouniverso There's the iteration limit.
very nice @hughgrigg , whenever possible I'll get the most recent version and adapt to use your iterator instead of mine