API other versions are not working as expected but targeting default version controllers on Heroku server

[hasnat-we]

Q	A
Bug?	no
New Feature?	no
Framework	Laravel
Framework version	8.66
Package version	3.1.1
PHP version	7.4.33

Actual Behaviour

All of our API v1 endpoints are working fine, regardless header version presence.
All v2 endpoints also working fine on local/remote development server, except live Heroku server.

The v2 endpoints are not working well in Heroku server, calling v1 default version controllers.
In the Heroku server we have following command when deployment is complete:
php artisan cache:clear && php artisan config:cache && php artisan api:cache

We defined our endpoints in routes/api.php as following:

include base_path('routes/api_v1.php');
include base_path('routes/api_v2.php');

Codes of routes/api_v1.php:

use Api\V1\Auth\Http\Controllers\LoginRequestController;

$api = app(Dingo\Api\Routing\Router::class);
$api->version('v1', ['middleware' => ['api', 'jwt.check']], function (\Dingo\Api\Routing\Router $api) {
    $api->group([
        'prefix' => 'auth',
    ], function (\Dingo\Api\Routing\Router $api) {
        $api->post('login-token', LoginRequestController::class)->name('api.auth.login_token');
    });
});

Codes of routes/api_v2.php:

use Api\V2\Auth\Http\Controllers\LoginRequestController;

$api = app(Dingo\Api\Routing\Router::class);
$api->version('v2', ['middleware' => ['api', 'jwt.check']], function (\Dingo\Api\Routing\Router $api) {
    $api->group([
        'prefix' => 'auth',
    ], function (\Dingo\Api\Routing\Router $api) {
        $api->post('login-token', LoginRequestController::class)->name('api.auth.login_token');
    });
});

The config/api.php codes are not changed.

My env vars are:

API_STANDARDS_TREE=vnd
API_SUBTYPE=myapp
API_VERSION=v1
API_PREFIX=api
API_NAME="MyApp API"
API_CONDITIONAL_REQUEST=false
API_STRICT=false
API_DEBUG=true

The headers I am sending for v2 endpoints in Postman:

Accept: application/vnd.myapp.v2+json
Content-Type: application/json

I verified Heroku server headers by \Log::info() and headers were NOT altered by load balancer.

Expected Behaviour

All v2 endpoints should call appropriate v2 response controllers same as local/remote development server. May be something going wrong with the optimization route cache commands this Dingo package facing trouble.

Steps to Reproduce

This is happening for me on fresh Dingo project sadly.

Possible Solutions

I believe the behavior is v2 is different between development and Heroku server is the caching process.

Update: 3 May, 2023: I removed the config and api route caching command from release phase for testing purpose in Heroku but sadly still it is not working as expected sadly. php artisan config:cache && php artisan api:cache

[specialtactics]

What happens if you don't do api:cache then?

[hasnat-we]

@specialtactics Thanks for your quick reply. So later I tested without caching config and api caching command. Sadly still there is no benefit. Still it was targeting the v1 controller instead v2 controller.

I was sending valid v2 header application/vnd.myapp.v2+json ideally. May be this is very rare case for me and others did not fall in this particular issue.

[specialtactics]

Is the only thing you are doing is sending the header? I am under the impression you actually need to prefix with /v2. By default the API through dingo has a prefix of /v1/ it's just that you can omit it, so if you want to use v2, I'm pretty sure you need to use this prefix.

So if you have https://domain.com for example and a route of /users you would need to go to https://domain.com/v2/users to use the v2 API.

[hasnat-we]

@specialtactics Actually everything is working fine in development environment. But when pushed in production env read-only server like Heroku, v2 endpoints targeting v1 controllers.

By theory as long I know, among 4 types version control system, either I should go with path /api/v2/ or custom accept header, any one at a time. But it worked well for development env.

I tried removing config and route command from Heroku live server deployment flow but still there was no luck.

So sadly now I am converting all Dingo api endpoints into Laravel standard api end-points as no other way.

[specialtactics]

Given that information, sounds like a problem with Heroku, something weird it's doing like dropping the header for example.

In any case good luck.

[hasnat-we]

@specialtactics Hi. I logged the headers from controller and I found the header was OK and not altered. But overall yes it looks like problem on Heroku server anyway. Thanks for closing this.