Skip to content

bug: log_entries property labels object_type values as Object ID in CoreStandardCheck messages #1041

@DharmaBytesX

Description

@DharmaBytesX

Component

Python SDK

Infrahub SDK version

1.20.1

Current Behavior

The InfrahubCheck.log_entries property in infrahub_sdk/checks.py formats the
object_type field of a log record with the literal label Object ID: instead
of Object Type:. As a result, whenever a check calls self.log_error(...) or
self.log_info(...) with both object_id and object_type, the rendered
string produces two consecutive Object ID: lines, the second of which is
actually the type name.

The defect lives in the property body:

@property
def log_entries(self) -> str:
    output = ""
    for log in self.logs:
        output += "Message: {}\n".format(log['message'])
        output += "Level: {}\n".format(log['level'])
        if "object_id" in log:
            output += "Object ID: {}\n".format(log['object_id'])
        if "object_type" in log:
            output += "Object ID: {}\n".format(log['object_type'])  # mislabeled
    return output

The string built by this property is what Infrahub stores on the
CoreStandardCheck.message field and what infrahubctl check run prints to
the terminal, so the mislabel is visible to every consumer of the SDK that
emits a log entry containing an object_type.

Expected Behavior

The label associated with the object_type value should read Object Type:,
producing one Object ID: line for the identifier and one Object Type: line
for the type. The corrected output for a single error log entry with both
fields should look like this:

Message: Duplicate serial '12345' for manufacturer 'Acme'.
Level: ERROR
Object ID: abc 123
Object Type: DcimDeviceAsset

Steps to Reproduce

  1. Install infrahub sdk 1.20.1.

  2. In a Python session, define a minimal subclass of InfrahubCheck:

    from infrahub_sdk.checks import InfrahubCheck
    
    class DemoCheck(InfrahubCheck):
        query = "noop"
        def validate(self, data):
            pass
    
    c = DemoCheck(branch="main")
    c.log_error(
        message="Duplicate serial",
        object_id="abc 123",
        object_type="DcimDeviceAsset",
    )
    print(c.log_entries)
  3. Observe the printed output. The line that should read
    Object Type: DcimDeviceAsset instead reads Object ID: DcimDeviceAsset.

The same mislabel is observable on a real Infrahub instance by registering a
check that uses object_type, triggering it through a proposed change, and
reading CoreStandardCheck.message over GraphQL.

Additional Information

Suggested fix, a single token edit on the affected line of
infrahub_sdk/checks.py:

if "object_type" in log:
    output += "Object Type: {}\n".format(log['object_type'])

A regression test could assert that, for a check that logs an error with both
object_id and object_type, the rendered string contains exactly one
Object ID: line and exactly one Object Type: line.

Context: this defect was identified while investigating opsmill/infrahub#8224
(the one character per line rendering bug). It is a separate defect with a
different root cause and a different surface, and it persists independently of
how that issue is resolved. It can be fixed in either order.

Optional follow up, not part of this report: the log_entries property has a
list sounding name but returns a single str, which contributed to the misuse
observed in opsmill/infrahub#8224. Adding an explicit return type annotation,
and optionally exposing a clearer alternative name such as formatted_logs,
would make the contract harder to misread. Out of scope for this typo fix.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions