The Guardian is an innovative open-source platform that streamlines the creation, management, and verification of digital environmental assets. It leverages a customizable Policy Workflow Engine and Web3 technology to ensure transparent and fraud-proof operations, making it a key tool for transforming sustainability practices and carbon markets.
Apache License 2.0
100
stars
129
forks
source link
Refreshing of available filter state on Guardian (Potential Caching Issue) #3641
The Guardian API seems to have a caching issue where data that has recently been pushed to a interfaceSourceDataBlock isn't filterable (if there is a filter block) connected to it.
When data is submitted to a block, within the context of using a filter to create a restful interface for Guardian the new data is not filtrable, unless the filter block itself is fetched to cache the new filterable values.
The API should be intelligent enough to know what values can be filtered upon, without the cache updated through a separate API call.
Step to reproduce
This issue is mitigated through the UI by default, it requires using the API directly.
More specifically:
Linking to a policy in a dry run state
Creating new users
Auth as the new user
Assigning a user to a particular role
Submitting data to a specific block
Waiting a period of time (5 seconds) for Guardian to catch up
Auth as standard registry
Refresh data by fetching via tag
Set stateful filter
Fetch filtered block data
Expected behavior
You should be able to filter data for a specific block without having to refresh the underlying data cache.
Problem description
The Guardian API seems to have a caching issue where data that has recently been pushed to a interfaceSourceDataBlock isn't filterable (if there is a filter block) connected to it.
When data is submitted to a block, within the context of using a filter to create a restful interface for Guardian the new data is not filtrable, unless the filter block itself is fetched to cache the new filterable values.
The API should be intelligent enough to know what values can be filtered upon, without the cache updated through a separate API call.
Step to reproduce
This issue is mitigated through the UI by default, it requires using the API directly.
More specifically:
Expected behavior
You should be able to filter data for a specific block without having to refresh the underlying data cache.
Screenshots
See loom: https://www.loom.com/share/768c25102ddd4e1086f2de43ecc4fc25
Example test code in my new client: