Fix dictionary hashing with pydantic models as keys

[apost71]

PR to address issue #392

[logan-markewich]

I'm not sure I like this change. This is not idempotent (its changing the context dict without the user knowing, and not changing it back) -- tbh, probably better to just do hash(str(context_dict) + hash_secret) ?

[apost71]

good point, updated and added a test

[coveralls]

coverage: 73.778% (+0.06%) from 73.723%
when pulling 049dd98 on apost71:main
into 5c3b425 on run-llama:main.

[masci]

I included in this PR the fix for the rabbitmq e2e tests, so the ones failing now are actual failures related to this changeset Please ignore, I see the same failure on main, having a look now.

[apost71]

I included in this PR the fix for the rabbitmq e2e tests, so the ones failing now are actual failures related to this changeset Please ignore, I see the same failure on main, having a look now.

I pushed a change that I think fixed the tests but I don't think I fixed the underlying issue - it seems like the hash is being computed by some other process that I can't find. The model_validator should look like this:

    @model_validator(mode="before")
    @classmethod
    def validate_hash(cls, data: Any) -> Any:
        if isinstance(data, dict):
            if "hash" not in data and "state" in data:
                data["hash"] = hash(str(data["state"]) + hash_secret)
        return data

but the tests fail if I allow that hash to be provided

[apost71]

@masci I discovered the issue is that the pydantic dict validation can make some small changes to the structure, specifically it was changing a tuple to a sequence that was breaking the hash checks. By making the hash a computed field in the pydantic model we can ensure that the hash is always computed based on the validated dict. I also changed the hashing to use zlib.adler32 because the vanilla hash method is based on memory locations which could cause issues if the hashes are ever computed in different processes.