[BUG] Flow.input_history is referenced by two docstrings but does not exist

Aperta
  • Qualcosa non va?
#9,216 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@lxcxjxhx ci sta già lavorando.

Dal 7/11/2026.

  • #9218 di @lxcxjxhx — aperta

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Ferma
Stack tecnologico
python
Ambito
backend

Direzione di ricerca

Start in crewai/flow/runtime/__init__.py, where the issue says _input_history is defined, and read the references in crewai/flow/conversation.py and crewai/flow/input_provider.py. Check the existing flow tests for history behavior, then verify that callers can inspect the prompt, response, and metadata through the documented API. A linked open pull request (#9218) is already addressing this issue.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Flow.input_history is referenced by two module docstrings but does not exist

What

crewai/flow/conversation.py:232 documents its input as "Convert Flow.input_history entries to LLM message format", and crewai/flow/input_provider.py:68 explains that "The response metadata is stored in _input_history". But Flow exposes no public input_history; the history exists only as a private pydantic attribute.

On crewai==1.15.37, installed from this repository's lib/crewai:

>>> from crewai.flow import Flow
>>> hasattr(Flow, "input_history")
False
>>> "_input_history" in Flow.__private_attributes__
True

So the only way to read what Flow.ask() asked and what came back — the request message, the response, the request metadata and the provider's InputResponse.metadata — is the private attribute.

Why it matters

This is the accessor that makes InputProvider/InputResponse usable: without it, a custom provider can carry response metadata but nothing documented can read it back. It also blocks the docs task in #8071, whose acceptance criteria say "show how to inspect response metadata using the existing flow.input_history API" — that criterion cannot be satisfied today.

Reproduction (scripted provider, no console, no LLM):

from crewai.flow import Flow, start
from crewai.flow.input_provider import InputResponse


class ScriptedProvider:
    def request_input(self, message, flow, metadata=None):
        return InputResponse(text="vector databases", metadata={"answered_by": "script"})


class ResearchFlow(Flow):
    input_provider = ScriptedProvider()

    @start()
    def gather(self):
        return self.ask("What should we research?", metadata={"channel": "#research"})


flow = ResearchFlow()
print(flow.kickoff())              # vector databases
print(flow._input_history)         # the metadata only exists here
print(hasattr(flow, "input_history"))  # False

Suggested fix (small, no behaviour change)

@property
def input_history(self) -> list[InputHistoryEntry]:
    """Return the ``Flow.ask()`` requests this flow has served.

    Each entry carries the prompt, the response (``None`` when the provider had
    nothing to give), the method that asked, the timestamp, the request metadata and
    the provider's ``InputResponse.metadata``.

    Returns:
        list[InputHistoryEntry]: A copy, so callers cannot mutate the flow's history.
    """
    return list(self._input_history)

InputHistoryEntry is already imported at the top of crewai/flow/runtime/__init__.py (line 128) for the private attribute's annotation, so this needs no new imports. Returning a copy keeps the existing append-only contract.

Note

I raised this in #8071 before writing the guide section, because the example the issue asks for would otherwise have to teach the private attribute. Happy to send the property + a unit test as the PR for this issue if you want it; the docs example then follows in #8071.

Lingua principale
Python
Stelle
60.6k
Fork
9.1k
Merge medio
1g 4h
PR unite (30g)
214

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di crewAIInc/crewAI

Tutte le issue di crewAIInc/crewAI

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.