To diagnose this, It would be useful to know what versions of Dazl and Daml you are using. (And @chrslg is right in that it would also be useful to have the full stack trace and exception message.)

That said, I have an example implementation of some Python code that uses Dazl 8.4.2 to query a Sandbox ledger from the Daml 2.10.1 SDK. You can find it here: https://github.com/mschaef-da/daml-cx-kb-demos/tree/main/dazl-client

The Python code specifically is here: https://github.com/mschaef-da/daml-cx-kb-demos/blob/main/dazl-client/main.py

The entry point establishes a connection to the sandbox and passes it into a function that executes the query against the stream:

async def main():
    async with dazl.connect(url='http://localhost:6865', read_as=alice_party_id()) as conn:
        await show_create_events(conn)

The query itself is written like this:

async def show_create_events(conn):
    async with conn.stream_many(tid) as stream:
        async for event in stream.items():
            if isinstance(event, Boundary):
                break

            print(pprint.pformat({
                '_cid': event.contract_id.value,
                '_tid': event.contract_id.value_type,
                'payload': event.payload
            }))
            print()

The call to stream_many opens a stream of events for the contract template ID in question and the async for iterates over the elements of that stream, printing each event in oldest-to-newest sequence.

By default stream_many will initially contain a create event for every contract that is active at the point of the query. Once it's sent events for all of these pre-existing contracts, it transitions to sending events representing current business process. The reason the sample loop breaks at the Boundary is that it displays only contracts that are active at the point of the query - it doesn't report current events. If you're interested in ongoing business processes, you won't want to stop at the Boundary. This will cause the loop to run indefinitely (and you will also have to handle archived events, which can start appearing once the stream is past the initial contracts.)

One other detail worth mentioning is the computation of tid... the template ID for the contract being queries. There's logic in place to discover the main package ID of the Daml model being queried and use that to explicitly populate the package ID in the tid . This results in a value for tid that looks like this (fully qualified):

e2e508ab6018568d0e8ce07dccc6c7288ad9744a6b8e5c826e1a19431c9cba09:Main:Asset