Requests to update schema version description are handled by UnitCommands instead of SchemaVersionCommands

[wwerner]

For updates to the schema version's description, an Exception is thrown:

08:33:28.235 [pool-2-thread-7] ERROR io.vlingo.actors.Logger - Default before resume recovery after: Invalid UUID string: 6ffcb30e-53c1-4ca7-8164-476fbc4e7da6/contexts/f4f8795d-6647-474b-8daf-a3250e83bbba/schemas/2e561b9b-7eb5-4ac6-819d-cec3bc56885f/versions/8b51a3e0-a4f6-4dbc-9080-b5e9bdff78f2
java.lang.IllegalArgumentException: Invalid UUID string: 6ffcb30e-53c1-4ca7-8164-476fbc4e7da6/contexts/f4f8795d-6647-474b-8daf-a3250e83bbba/schemas/2e561b9b-7eb5-4ac6-819d-cec3bc56885f/versions/8b51a3e0-a4f6-4dbc-9080-b5e9bdff78f2
    at java.util.UUID.fromString(UUID.java:194) ~[na:1.8.0_212]
    at io.vlingo.lattice.grid.GridAddressFactory.from(GridAddressFactory.java:45) ~[classes/:na]
    at io.vlingo.lattice.router.RoutableCommand.handleWithin(RoutableCommand.java:191) ~[classes/:na]
    at io.vlingo.lattice.router.CommandRouterWorkerActor.route(CommandRouterWorkerActor.java:32) ~[classes/:na]
    at io.vlingo.lattice.router.CommandRouter__Proxy.lambda$route$0(CommandRouter__Proxy.java:32) ~[classes/:na]
    at io.vlingo.actors.LocalMessage.internalDeliver(LocalMessage.java:115) ~[classes/:na]
    at io.vlingo.actors.LocalMessage.deliver(LocalMessage.java:47) ~[classes/:na]
    at io.vlingo.actors.plugin.mailbox.concurrentqueue.ConcurrentQueueMailbox.run(ConcurrentQueueMailbox.java:101) ~[classes/:na]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) ~[na:1.8.0_212]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ~[na:1.8.0_212]
    at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_212]

It seems that instead of describeAs in SchemaVersionCommands, the command of the same name in UnitCommands is called. I currently can't see where this comes from.

To reproduce, create an org/unit/context/schema/schemaVersion and request the following:

PATCH http://localhost:9019/organizations/{{orgId}}/units/{{unitId}}/contexts/{{contextId}}/schemas/{{schemaId}}/versions/{{schemaVersionId}}/description
Content-Type: application/json

with a body of updated description.

Note that the content type needs to be application/json instead of text/plain, see https://github.com/vlingo/vlingo-http/issues/49

The analogue to update a schema version specification works as expected:

PATCH http://localhost:9019/organizations/{{orgId}}/units/{{unitId}}/contexts/{{contextId}}/schemas/{{schemaId}}/versions/{{schemaVersionId}}/specification
Content-Type: application/json

updated spec

Interesting to note that it calls a command of the same name but in a different class. The handler does reference the correct command in SchemaVersion commands.

[wwerner]

It it not the wrong command that is triggered first but the handler before. PATCH /organizations/<orgId>/units/<unitId>/contexts/<contextId>/schemas/<schemaId>/versions/<schemaVersionId>/description is getting handled by UnitResource.describeAs mapped to /organizations/{organizationId}/units/{unitId}/description instead of by SchemaVersionResource.describeAs mapped to /organizations/{organizationId}/units/{unitId}/contexts/{contextId}/schemas/{schemaId}/versions/{schemaVersionId}/description

The {unitId} param is set to everything in between unitId/ and /description, so GridAddressFactory tries to parse a UUID from a string like <UUID>/schemas/<UUID>/versions/<UUID>.

I'd guess that sth. in the way resource URLs are matched is broken.

[wwerner]

Here are the relevant mappings as logged when starting the server:

• Action: id=0, method=PATCH, uri=/organizations/{organizationId}/units/{unitId}/contexts/{contextId}/schemas/{schemaId}/versions/{schemaVersionId}/description, to=dynamic1(String organizationId, String unitId, String contextId, String schemaId, String schemaVersionId) -> should handle the request
• Action: id=0, method=PATCH, uri=/organizations/{organizationId}/units/{unitId}/description, to=dynamic1(String organizationId, String unitId) -> actually does handle it

[VaughnVernon]

@wwerner Suggestion. Register the resources with the same pattern, but that are lengthier URIs, earlier:

    Resources allResources = Resources.are(
            organizationResource.routes(),
            unitResource.routes(),
            contextResource.routes(),
            schemaResource.routes(),
            schemaVersionResource.routes(),
            codeResource.routes(),
            uiResource.routes()
    );

Becomes:

    Resources allResources = Resources.are(
            schemaVersionResource.routes(),
            schemaResource.routes(),
            contextResource.routes(),
            unitResource.routes(),
            organizationResource.routes(),
            codeResource.routes(),
            uiResource.routes()
    );

Let me know if this fixes the problem. I think it will and should be documented as a requirement.