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

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.