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
-
Install infrahub sdk 1.20.1.
-
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)
-
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.
Component
Python SDK
Infrahub SDK version
1.20.1
Current Behavior
The
InfrahubCheck.log_entriesproperty ininfrahub_sdk/checks.pyformats theobject_typefield of a log record with the literal labelObject ID:insteadof
Object Type:. As a result, whenever a check callsself.log_error(...)orself.log_info(...)with bothobject_idandobject_type, the renderedstring produces two consecutive
Object ID:lines, the second of which isactually the type name.
The defect lives in the property body:
The string built by this property is what Infrahub stores on the
CoreStandardCheck.messagefield and whatinfrahubctl check runprints tothe 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_typevalue should readObject Type:,producing one
Object ID:line for the identifier and oneObject Type:linefor the type. The corrected output for a single error log entry with both
fields should look like this:
Steps to Reproduce
Install
infrahub sdk1.20.1.In a Python session, define a minimal subclass of
InfrahubCheck:Observe the printed output. The line that should read
Object Type: DcimDeviceAssetinstead readsObject 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, andreading
CoreStandardCheck.messageover GraphQL.Additional Information
Suggested fix, a single token edit on the affected line of
infrahub_sdk/checks.py:A regression test could assert that, for a check that logs an error with both
object_idandobject_type, the rendered string contains exactly oneObject ID:line and exactly oneObject 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_entriesproperty has alist sounding name but returns a single
str, which contributed to the misuseobserved 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.