Add currentFuelPercent and currentRangeMeters to RentalVehichle in the GTFS GraphQL API

[JustCris654]

Summary

Add currentFuelPercent and currentRangeMeters fields to RentalVehicle in the graphql GTFS API

Issue

issue

I added currentRangeMeters on top of the issue because it is related

Unit tests

Write a few words on how the new code is tested.

• Graphql integration test have been modified to test this fields
• I tested the query with the graphiql frontend
• Do all tests
  pass the continuous integration service
  ? Yes

Documentation

• I wrote the proper doc comments in the graphql schema

[codecov]

Codecov Report

Attention: Patch coverage is 57.69231% with 22 lines in your changes missing coverage. Please review.

Project coverage is 69.84%. Comparing base (5f9b448) to head (284133a).

Files with missing lines	Patch %	Lines
...ental/datasources/GbfsFreeVehicleStatusMapper.java	52.17%	10 Missing and 1 partial ⚠️
.../opentripplanner/transit/model/basic/Distance.java	40.00%	3 Missing and 3 partials ⚠️
...org/opentripplanner/transit/model/basic/Ratio.java	60.00%	4 Missing ⚠️
.../apis/transmodel/model/stop/RentalVehicleType.java	0.00%	1 Missing ⚠️

Additional details and impacted files

@@              Coverage Diff              @@
##             dev-2.x    #6272      +/-   ##
=============================================
- Coverage      69.85%   69.84%   -0.01%     
- Complexity     17921    17940      +19     
=============================================
  Files           2035     2037       +2     
  Lines          76495    76542      +47     
  Branches        7824     7831       +7     
=============================================
+ Hits           53434    53463      +29     
- Misses         20324    20341      +17     
- Partials        2737     2738       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[optionsome]

Does the library we use validate that the fuel percent is between 0 and 1 or should we do it?

[JustCris654]

Does the library we use validate that the fuel percent is between 0 and 1 or should we do it?

The library validate if the value is between 0 and 1 in output (when generating the graphql response).
It returns an error like this:

{
  "errors": [
    {
      "message": "Can't serialize value (/rentalVehicles[0]/currentFuelPercent) : Value is under 0 or greater than 1.",
      "path": [
        "rentalVehicles",
        0,
        "currentFuelPercent"
      ],
      "extensions": {
        "classification": "DataFetchingException"
      }
    }
  ],
  "data": {
    "rentalVehicles": [
      {
        "name": "Ninebot A200",
        "lat": 43.772581,
        "lon": 13.132542,
        "currentFuelPercent": null
      }
    ]
  }
}

The value is not checked when received in the gbfs mapper, do we need to check it also there? I saw that in the RatioScalarTest.java has this

    var ratio = (Double) GraphQLScalars.RATIO_SCALAR.getCoercing().parseValue(HALF);

to parse a value.

[optionsome]

The value is not checked when received in the gbfs mapper, do we need to check it also there?

I would prefer to log some warning and ignore the value in the mapper instead of letting it be cause issues in the APIs.

[optionsome]

@testower do you know if there is some general policy in the GBFS java library for validating values (such as not allowing over 100% fuel percent or negative range meters)?

[testower]

@testower do you know if there is some general policy in the GBFS java library for validating values (such as not allowing over 100% fuel percent or negative range meters)?

The java model used in otp does not have validation annotations, so anything that can be deserialized is accepted.

[optionsome]

The java model used in otp does not have validation annotations, so anything that can be deserialized is accepted.

Is there an option to use validation annotations? I'm just wondering should we discuss the possibility in tomorrow's dev meeting, for example?

[testower]

Not with the current library. It is left out with intention. I don't think validation should be handled in the deserialization step anyway. This is runtime code / hot code path, so I think OTP should validate the data it needs to in the business layer.

[testower]

I should probably add some reasoning: I don't think it's desirable to reject the deserialization of a whole file update, because some particular piece of data in that update doesn't validate according to the validation annotations. The data may still be perfectly usable by OTP.

[leonardehrenfried]

You need to resolve merge conflicts.

[JustCris654]

I added this check, can you double check if it's right?
I'm not sure but vehicle_type_id is REQUIRED if the vehicle_types.json file is defined, that file is REQUIRED for systems with free_bike_status.json and if this file is not included then all vehicles are non motorized bicycles.
Therefore if the vehicleTypeId is not present in the vehicleTypes map I can assume that the file vehicle_types.json is not present and all vehicles are not motorized, so the propulsion type is human and range is not needed.