pytest_bdd_apply_tag does not detect Gherkin example tags

[calgray]

Is your feature request related to a problem? Please describe.
Tags on example tables are not picked up by the pytest_bdd_apply_tag.

i.e.

Feature: My Feature
    Scenario: My scenario case <case>
    
    Examples:
        | case |
        | 1    |
        | 2    |

    @xfail @supresswarning=DeprecationWarning
    Examples:
        | case |
        | 3    |

case 3 does get marked with xfail, but pytest_bdd_apply_tag never sees either tag.

Describe the solution you'd like
All tag locations supported by Gherkin features are intercepted by the tag hook.

Describe alternatives you've considered
Use custom tags on the entire scenario
Use @xfail and @skip tags without specifying a reason
Use request.node.add_marker() in relevent python steps that can branch on example parameters

Additional context
@skip and @xfail are working for example tables, but they and new tags can't be customised.

[mike-lowe-youview]

+1
It's great that @skip and @xfail work out of the box but without the ability to pass a reason string it's a big loss to the test report. I'd be happy to parse the failure reason from the tag string e.g. @xfail("JIRA-1234") in the pytest_bdd_apply_tag() and call pytest.mark.xfail(reason="my_parsed_string") from there if I could but as per this issue reported; example table tags just aren't being seen by the pytest_bdd_apply_tag hook which leaves no possible way to add a xfail or skip reason from the feature file.

[mike-lowe-youview]

Following up with a solution that worked for us. It's not a solution to pytest_bdd_apply_tag not seeing tags but with a workaround that uses the pytest_collection_modifyitems() hook we were able to take the markers, parse them and re-apply as proper markers like this:

def pytest_collection_modifyitems(items: list[pytest.Item]) -> None:
    """Pytest hook: convert xfail marks from Examples-block tags into real ones.
    pytest-bdd applies Examples-block tags (including @xfail) via
    getattr(pytest.mark, tag), so @xfail(reason="TICKET-123") produces a mark
    literally named "xfail(reason="TICKET-123")" rather than pytest.mark.xfail.
    This means a row in the Examples table marked with @xfail(reason="TICKET-123") will not be marked
    as xfail in the test results.
    This hook finds the literal marks added by pytest-bdd, removes them, and replaces them
    with a proper pytest.mark.xfail(reason=...) so the reason appears in the test report.
    Usage in feature files::
        @xfail(reason="TICKET-123")
        Examples:
            | col  |
            | val  |
    :param list[pytest.Item] items: All collected test items.
    """
    for item in items:
        for marker in list(item.iter_markers()):
            if match := re.compile(r'^xfail\(reason="(.+?)"\)$').match(marker.name):
                item.own_markers.remove(marker)
                item.add_marker(pytest.mark.xfail(reason=match.group(1), strict=False))

[golikovichev]

The asymmetry between scenario-level tags and example-level tags shows up in src/pytest_bdd/scenario.py:

Scenario, feature, and rule tags flow through the hook (around line 327):

for tag in templated_scenario.tags | feature.tags | rule_tags:
    config.hook.pytest_bdd_apply_tag(tag=tag, function=scenario_wrapper)

Example-block tags bypass the hook and are applied as raw marks inside collect_example_parametrizations (around line 345):

example_marks = [getattr(pytest.mark, tag) for tag in tags]

The second path is what produces the literal-named marks @mike-lowe-youview's workaround targets. @xfail(reason="TICKET-123") survives Gherkin parsing as the string xfail(reason="TICKET-123"), then getattr(pytest.mark, ...) builds a mark object whose name is that whole string, so no hook ever sees the tag.

A minimal fix could route example-level tags through pytest_bdd_apply_tag the same way scenario tags go. The wrinkle is that collect_example_parametrizations returns pytest.param(..., marks=[...]) rather than applying marks to a function, so the hook would need a way to expose the resolved marks back to the caller (or the function could call the hook on a small shim and pick up its pytestmark). Happy to dig further if maintainers have a preferred direction.

Source-traced read only; did not run a local repro on top of this.