Skip to content

Custom component input field named 'index' (or other reserved Component attribute) silently resolves to the wrong value #15068

Description

@mjobrien05

Bug Description

Naming a custom component input field a common word that happens to collide with an existing Component base-class attribute or method silently breaks field access, with no validation or warning anywhere in the pipeline.

Concretely: naming a field index means self.index inside the component resolves to the real inherited method Component.index, not the field's configured value — plain Python attribute lookup finds the class member before Langflow's own field-population/resolution mechanism ever gets a chance to override it. setattr(self, "index", value) at construction time does technically shadow it for direct attribute access afterward in isolated testing, but going through the real graph build path — where the field is populated from the node's template rather than by direct assignment — the collision reproduces reliably.

The resulting failure is actively misleading rather than a clean crash: the bound method object gets interpolated into unrelated string-building code (e.g. an f-string constructing a URL or error message), producing something like:

<bound method CustomComponent.index of <... object at 0x7f...>> not found

— which gives no hint that the real problem is a field-name collision. This was only found by comparing an isolated, manually-constructed component instance (works correctly) against the identical logic driven through a real graph build (silently wrong), then checking dir(Component) to confirm index is a real reserved name.

dir(Component) on a recent build returns dozens of names that would collide the same way if chosen as a field name — a non-exhaustive sample: index, name, code, data, run, log, set, graph, template, build, description, status, outputs, inputs.

Reproduction

from lfx.custom.custom_component.component import Component
from lfx.inputs.inputs import MessageTextInput
from lfx.template.field.base import Output
from lfx.schema.data import Data

class Repro(Component):
    display_name = "Repro"
    name = "Repro"
    inputs = [MessageTextInput(name="index", display_name="Index", required=True)]
    outputs = [Output(display_name="Result", name="result", method="run")]

    def run(self) -> Data:
        # self.index resolves to the inherited Component.index METHOD here,
        # not the field value set via the node's template.
        return Data(data={"index_value": self.index})

Build this as a real flow node (not a directly-instantiated/manually-assigned Python object) and inspect the index_value field in the result — it will be a bound-method repr rather than the string configured on the node.

Expected behavior

One of:

  • Reject field names that collide with an existing Component attribute or method at component registration/validation time, with a clear error naming the collision.
  • Namespace user-defined fields separately from the class's own attribute namespace (e.g. resolve field access through a dedicated accessor rather than plain instance-attribute lookup), so this class of collision can't happen regardless of field name.

Either would turn this from a silent, hard-to-diagnose wrong-value bug into a loud, immediately-understandable one.

Who can help?

No response — filed from direct debugging, not familiar with current code ownership for lfx/custom.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't workingjiraThis issue has been logged in Jira for fix by the engineering team.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions