process_event_rules() broke all events when condition evaluation contains None values. #11251

@jnovinger commented on GitHub (Jun 3, 2025):

Thank you for opening a bug report, @ravenrs . Unfortunately, the information you have provided is not sufficient for someone else to attempt to reproduce the reported behavior. Remember, each bug report must include detailed steps that someone else can follow on a clean, empty NetBox installation to reproduce the exact problem you're experiencing. These instructions should include the creation of any involved objects, any configuration changes, and complete accounting of the actions being taken. Also be sure that your report does not reference data on the public NetBox demo, as that is subject to change at any time by an outside party and cannot be relied upon for bug reports.

@jnovinger commented on GitHub (Jun 3, 2025): Thank you for opening a bug report, @ravenrs . Unfortunately, the information you have provided is not sufficient for someone else to attempt to reproduce the reported behavior. Remember, each bug report must include detailed steps that someone else can follow on a clean, empty NetBox installation to reproduce the exact problem you're experiencing. These instructions should include the creation of any involved objects, any configuration changes, and complete accounting of the actions being taken. Also be sure that your report does not reference data on the public NetBox demo, as that is subject to change at any time by an outside party and cannot be relied upon for bug reports.

adam commented

@ravenrs commented on GitHub (Jun 4, 2025):

@jnovinger Hi, trust me it's enough to reproduce, I do the same in Prod/Test/Dev enviroment. Only you need the same version and event with condition that contains error, but ok, I will explain all steps from scratch.

@ravenrs commented on GitHub (Jun 4, 2025): @jnovinger Hi, trust me it's enough to reproduce, I do the same in Prod/Test/Dev enviroment. Only you need the same version and event with condition that contains error, but ok, I will explain all steps from scratch.

adam commented

@ravenrs commented on GitHub (Jun 4, 2025):

@jnovinger I've change description of issue, but it doesn't matter what to change site/device, all events with the same obj_type won't added to queue and will drop silence.

@ravenrs commented on GitHub (Jun 4, 2025): @jnovinger I've change description of issue, but it doesn't matter what to change site/device, all events with the same obj_type won't added to queue and will drop silence.

adam commented

@jnovinger commented on GitHub (Jun 4, 2025):

@jnovinger I've change description of issue, but it doesn't matter what to change site/device, all events with the same obj_type won't added to queue and will drop silence.

Thanks, I'll take a look at the updated STR as soon as I can.

@jnovinger commented on GitHub (Jun 4, 2025): > @jnovinger I've change description of issue, but it doesn't matter what to change site/device, all events with the same obj_type won't added to queue and will drop silence. Thanks, I'll take a look at the updated STR as soon as I can.

adam commented

@github-actions[bot] commented on GitHub (Jun 12, 2025):

This is a reminder that additional information is needed in order to further triage this issue. If the requested details are not provided, the issue will soon be closed automatically.

@github-actions[bot] commented on GitHub (Jun 12, 2025): This is a reminder that additional information is needed in order to further triage this issue. If the requested details are not provided, the issue will soon be closed automatically.

adam commented

@ravenrs commented on GitHub (Jun 12, 2025):

@jnovinger please update status here

@ravenrs commented on GitHub (Jun 12, 2025): @jnovinger please update status here

adam commented

@ravenrs commented on GitHub (Jul 4, 2025):

@jnovinger Hi, I've fixed it, could you assign issue to me, to submit pull request.

@ravenrs commented on GitHub (Jul 4, 2025): @jnovinger Hi, I've fixed it, could you assign issue to me, to submit pull request.

adam commented

@jeremystretch commented on GitHub (Jul 8, 2025):

Event won't added to queue, don't brake all events in cycle or it can be validate somehow while creating event with such mistakes.

I'm not sure what you're trying to say here, but this appears to be working as expected on NetBox v4.3.3. The event rule does not trigger because the constraint is invalid: attr should be tenant.name rather than data.tenant.name. However, other event rules still trigger successfully after a failure.

@jeremystretch commented on GitHub (Jul 8, 2025): > Event won't added to queue, don't brake all events in cycle or it can be validate somehow while creating event with such mistakes. I'm not sure what you're trying to say here, but this appears to be working as expected on NetBox v4.3.3. The event rule does not trigger because the constraint is invalid: `attr` should be `tenant.name` rather than `data.tenant.name`. However, other event rules still trigger successfully after a failure.

adam commented

@ravenrs commented on GitHub (Jul 8, 2025):

@jeremystretch
Event doesn't return False and just skipped, it was a cause of TypeError. I've checked source of 4.3.3:

def process_event_rules(event_rules, object_type, event_type, data, username=None, snapshots=None, request_id=None):
    user = User.objects.get(username=username) if username else None

    for event_rule in event_rules:

        # Evaluate event rule conditions (if any)
        if not event_rule.eval_conditions(data):
            continue

        # Compile event data
        event_data = event_rule.action_data or {}
        event_data.update(data)

there is no "try except" in this cycle, so depending on the queue in this cycle, all subsequent events will be skipped.
I can test it on my local 4.3.3, if you want, but I don't think it's necessary, I added pull request to avoid Type error, but I didn't add try exept to this cycle so theoretically the result will be the same if some error appears. Do you agree?

@ravenrs commented on GitHub (Jul 8, 2025): @jeremystretch Event doesn't return False and just skipped, it was a cause of TypeError. I've checked source of 4.3.3: ``` def process_event_rules(event_rules, object_type, event_type, data, username=None, snapshots=None, request_id=None): user = User.objects.get(username=username) if username else None for event_rule in event_rules: # Evaluate event rule conditions (if any) if not event_rule.eval_conditions(data): continue # Compile event data event_data = event_rule.action_data or {} event_data.update(data) ``` there is no "try except" in this cycle, so depending on the queue in this cycle, all subsequent events will be skipped. I can test it on my local 4.3.3, if you want, but I don't think it's necessary, I added pull request to avoid Type error, but I didn't add try exept to this cycle so theoretically the result will be the same if some error appears. Do you agree?

adam commented

@jeremystretch commented on GitHub (Jul 8, 2025):

@ravenrs if you test for the behavior I've described you'll find that my statement is accurate.

The root issue here appears to be that the TypeError exception raised by the eval_contains() method when passed a null value is being accidentally swallowed by the flush_events() handler. So, the first step it to fix that, and ensure that any exception unrelated to the import of a function are raised appropriately. This will result in the TypeError being uncaught, exposing the secondary bug.

The secondary bug is that an invalid attr definition can result in passing an unexpected type to the evaluator methods. In this case, we're passing None where an iterable is expected, but I'm sure there are others. The fix for this is to catch and appropriately log any TypeError, ValueError, or similar exceptions.

@ravenrs are you interested in pursuing this work?

@jeremystretch commented on GitHub (Jul 8, 2025): @ravenrs if you test for the behavior I've described you'll find that my statement is accurate. The root issue here appears to be that the TypeError exception raised by the `eval_contains()` method when passed a null value is being accidentally swallowed by the [`flush_events()`](https://github.com/netbox-community/netbox/blob/8fb8f4c75b3e834fff5ffd596b8a8e391ad5fb17/netbox/extras/events.py#L186) handler. So, the first step it to fix that, and ensure that any exception unrelated to the import of a function are raised appropriately. This will result in the TypeError being uncaught, exposing the secondary bug. The secondary bug is that an invalid `attr` definition can result in passing an unexpected type to the evaluator methods. In this case, we're passing `None` where an iterable is expected, but I'm sure there are others. The fix for this is to catch and appropriately log any TypeError, ValueError, or similar exceptions. @ravenrs are you interested in pursuing this work?

adam commented

@ravenrs commented on GitHub (Jul 8, 2025):

@jeremystretch Yes, Im interested, I've implement workaround in my production environment, but i'm interested to have it in Upstream. I will check flush_events().

@ravenrs commented on GitHub (Jul 8, 2025): @jeremystretch Yes, Im interested, I've implement workaround in my production environment, but i'm interested to have it in Upstream. I will check flush_events().

adam commented