Include the Params field in the error response

[Alessandro100]

In the javascript gbfs validator they include the field params in the file error response. This extra data will give more information to the user as to why or what is going wrong in the file

Acceptance Criteria

• Include the params field in the file error response

[testower]

This was discussed in the design meetings for the openapi spec and was intentionally left out. Mostly because we don't have anything to put there.

[Alessandro100]

I might be forgetting or have missed that part of the design meeting since it’s been a while.
Could you elaborate a bit on what you mean by “nothing to put there”? From what I can see, there seem to be some data values that could fit.

from: https://dubai.publicbikesystem.net/customer/gbfs/v2/gbfs.json

[testower]

You're showing output from the ajv validator. The java validator lib doesn't provide this.

It was removed from the spec here 9f94a67 following a meeting. I don't remember if you were there.

[Alessandro100]

The main idea is to have parity with the JavaScript validator. If the Java validator library doesn’t provide this, would there be any workaround to get it? Otherwise, we can close this ticket.

I remember I was a part of some meetings but not all of them

[testower]

I guess it's possible but needs to be implemented programatically, so I guess for true feature parity we need to reverse engineer whatever ajv puts there. I distinctly remember we decided it's not needed and we can ignore this bit. @emmambd @davidgamez

[emmambd]

Thanks @testower! @Alessandro100's come back from paternity leave and is working on the UI for the GBFS validator. @davidgamez and I just asked him to document what pieces of functionality were "missing" compared to the JS validator and we would decide next contributor meeting what we want to include before UI launch. I do remember our discussion on this and the decision that it isn't critical for launch.

We can decide during the meeting if it's still worth pursuing in the future as a non-blocking item or not.

[davidgamez]

I guess it's possible but needs to be implemented programatically, so I guess for true feature parity we need to reverse engineer whatever ajv puts there. I distinctly remember we decided it's not needed and we can ignore this bit. @emmambd @davidgamez

We marked it as non-blocking, and the workaround might not be worth the effort vs the time and complexity. It's nice to have, but knowing which field has an invalid value might be sufficient for the consumer to fix the data by looking at the spec. We can review this in the next contributors meeting.

[testower]

Ok thanks for the context 👍

[Alessandro100]

After discussion, params will not be a blocker for initial release. We will keep the issue open as it would be a nice-to-have, but we will also explore different data that could be returned that would be helpful to end consumers of the API (ex: providing the station id that links to a certain error)