[jira] [Created] (CAMEL-25825) camel-test-dst - more pitfalls for agents writing worlds in the guide

["shashank (Jira)" <ji...@apache.org>]

shashank created CAMEL-25825:
--------------------------------

             Summary: camel-test-dst - more pitfalls for agents writing worlds in the guide
                 Key: CAMEL-25825
                 URL: https://issues.apache.org/jira/browse/CAMEL-25825
             Project: Camel
          Issue Type: Improvement
          Components: camel-test
            Reporter: shashank
            Assignee: shashank


The guide "Writing a fake world" of camel-test-dst (CAMEL-25738, {{test-dst.adoc}}) lists the pitfalls seen when agents wrote the first nine worlds. Writing worlds for IMAP, JMS, NATS JetStream and Azure Service Bus with the merged harness ran into more of them. Each one cost a round of false failures or a run that never ended, and each fits in one or two sentences of the guide.

*Change* (docs only, the module page and its catalog copy):
* "No end to the run" says what to do with a consumer task that never returns (a pull loop): it sits above the test thread on the one stack, so {{dst.runFor}} / {{dst.runUntil}} in the test body cannot return while it loops. The phases of the run become scheduled tasks, and the run ends by having the fake close the subscription, then {{runUntil(closed)}}.
* New pitfalls: a fake that answers at once with nothing makes a tight loop in which virtual time does not move (give it a round-trip latency); a {{java.lang.reflect.Proxy}} fake turns an undeclared checked exception into {{UndeclaredThrowableException}} (do what the library does); the fake must model what the client library does with objects of an earlier connection, not only the server; each kind of operator stop needs its own excuse record; a synchronous consumer over {{DstCamel.asyncStep}} needs {{DefaultAsyncProcessorAwaitManager}} in {{alsoRewrite}}, and the asynchronous exchanges in flight must finish before {{dropPending()}}.
* Running the tests: a component whose tests depend on a {{camel-test-infra-*}} module needs it in {{-pl}} when it is not in the local repository.
* Limits: a world in a module with parallel tests (camel-sjms, camel-jms) can be run alone with {{-Dcamel.surefire.parallel=false}} but cannot be committed there (the harness refuses to start under parallel JUnit, as before); locks do not exclude on the one stack, so races between two lock-holding code paths cannot be explored.

Each statement was checked against the harness on main ({{Dst}}, {{DstExtension}}, {{DstInstrumentation}}, {{DstCamel}}).

_Filed with Claude Code on behalf of allthingssecurity._




--
This message was sent by Atlassian Jira
(v8.20.10#820010)