`off_chain_vote_data` is not populated with data

[MSzalowski]

OS Your OS: Linux

Versions The db-sync version (eg cardano-db-sync --version): sancho-4-3-0 PostgreSQL version: 15.7

Build/Install Method The method you use to build or install cardano-db-sync: docker image

Run method The method you used to run cardano-db-sync (eg Nix/Docker/systemd/none): Docker

Additional context Happening on sancho govtool

Problem Report off_chain_vote_data is not populated with metadata.

Example query showing no metadata where such metadata exists.

select * from gov_action_proposal join voting_anchor on voting_anchor.id = gov_action_proposal.voting_anchor_id left join off_chain_vote_data on off_chain_vote_data.voting_anchor_id = voting_anchor.id where off_chain_vote_data is null;

[kderme]

Do these queries return empty? select * from off_chain_vote_data; select * from off_chain_vote_fetch_error;

[bosko-m]

@kderme Based on the info I got, off_chain_vote_fetch_error wasnt used/analyzed. Both off_chain_vote_data and off_chain_vote_fetch_error seem to return "some" results. We are investigating why it might be the case and this is the main error we are noticing:

Error Offchain Voting Anchor: JSON decode error from when fetching metadata from Just https://raw.githubusercontent.com/mpawel79/testrepo/master/Info.jsonld resulted in : "Error in $.body.references[0]: key \"label\" not found"

It might be that we missed label key being mandatory or similar, but we will hopefully be able to confirm that on Monday. CC @MSzalowski @jankun4

[kderme]

My interpretation of CIP-100 is that each reference must have a label

[MSzalowski]

So the problem is that this action uses reference-label instead of label, right? Having this set to label would make the off_chain_vote_data populated?

Second thing, references are optional based on CIP-108, would the empty array fail the validation?

[kderme]

So the problem is that this action uses reference-label instead of label, right? Having this set to label would make the off_chain_vote_data populated?

That's open to interpretation I think. CIP-100 mentions

Each object specifies a label, which serves as a human readable display name

db-sync takes this literally: a property called "label" needs to exist under "references". The example in question has an option called "CIP108:reference-label". Even if this changes to "CIP108:label", db-sync wouldn't accept it, because this is not exactly "label", even if according to json-ld it may equivalent.

There are cases that db-sync accepts like using "label" : {"@value": "Label"} instead of "label": "Label", but this is an exception.

As of https://github.com/cardano-foundation/CIPs/pull/835 I've attempted to reduce the dependency on json-ld and there will be a follow up to try to remove ambiguities like this one.

[kderme]

Second thing, references are optional based on CIP-108, would the empty array fail the validation?

No it shouldn't fail the validation.

[kderme]

db-sync defined a tool executable http-get-json-metadata which can be used to validate what metadata are accepted. There are no release binaries for it though.

[kderme]

Could we close this?

[MSzalowski]

Closed, thank you for your feedback around this topic and clarifying how things works :saluting_face: