- Issue created by @megachriz
Coming from 🐛 Feed fetch errors don't seem to be handled gracefully Active .
When an import starts, the feed gets locked for 12 hours. When the lock expires, Feeds checks if the import is perhaps still running by checking:
Only one of the above has to be true for the lock getting extended.
However, when an import gets stuck for whatever reason, Feeds may retry continue the import forever. In this scenario, when a task from the queue errors, the task remains on the queue, causing Feeds to think that the import is still active.
To get out of the loop, there should be a configurable limit for how many times the lock may be extended. With the default that is not extended. The only downside to this default is that people running imports that take longer than 12 hours to complete need to be pay extra attention to this setting, but the benefit is that there is by default a limit on how long imports can be a stuck state.
On the feed type settings, we could have the following setting:
Keep the feed locked if the import has not completed after the lock timeout
The lock timeout is: 12 hours (taken from feeds.settings.lock_timeout).
- Never (default)
- Always
- Extend the lock this many times at max: [number field]
In FeedLockBackend::lockMayBeAvailable()
, the setting should be checked for if it lock may be extended or not. If the setting is set to a number, it would need check a state variable to see how many times the lock for this feed was already extended. Then it need to plus that number and write that back to the state variable.
I think it makes sense to get the state this way, though it does require making the method getStateStorage()
public:
$lock_extended_count = $feed->getStateStorage()->get('lock_extended_count');
FeedTypeForm::form()
.Feed::getStateStorage()
public.getStateStorage()
method to FeedInterface.Active
3.0
Code