-
Notifications
You must be signed in to change notification settings - Fork 140
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Routing Weirdness Within a Chunk? #190
Comments
Hello! I can reproduce the issue with the latest release of the router, it looks like it's an edge case of #104. Apparently, the issue happens when a static route is mixed with a dynamic route, eg:
If you change the routes to:
|
I cannot reproduce the error with this test case, what am I missing? (tried 'use strict'
const t = require('tap')
const FindMyWay = require('../')
t.test('issue-190', (t) => {
t.plan(6)
const findMyWay = FindMyWay()
let staticCounter = 0
let paramCounter = 0
const staticPath = function staticPath () { staticCounter++ }
const paramPath = function paramPath () { paramCounter++ }
const extraPath = function extraPath () { }
findMyWay.on('GET', '/api/users/award_winners', staticPath)
findMyWay.on('GET', '/api/users/admins', staticPath)
findMyWay.on('GET', '/api/users/:id', paramPath)
findMyWay.on('GET', '/api/:resourceType/foo', extraPath)
t.equal(findMyWay.find('GET', '/api/users/admins').handler, staticPath)
t.equal(findMyWay.find('GET', '/api/users/award_winners').handler, staticPath)
t.equal(findMyWay.find('GET', '/api/users/a766c023-34ec-40d2-923c-e8259a28d2c5').handler, paramPath)
t.equal(findMyWay.find('GET', '/api/users/b766c023-34ec-40d2-923c-e8259a28d2c5').handler, paramPath)
findMyWay.lookup({
method: 'GET',
url: '/api/users/admins',
headers: { }
})
findMyWay.lookup({
method: 'GET',
url: '/api/users/award_winners',
headers: { }
})
findMyWay.lookup({
method: 'GET',
url: '/api/users/a766c023-34ec-40d2-923c-e8259a28d2c5',
headers: { }
})
t.equal(staticCounter, 2)
t.equal(paramCounter, 1)
}) |
Hi @Eomm there is a 4th route that is significant /api/:resourceType/foo |
Thanks, that one trigger the issue 👍🏽 |
@Eomm any update for this issue? |
I'm not working on it, I had the chance to reproduce it but not to fix it |
We are using old We cannot reproduce it in version 2
|
Would you like to work on this or fund the development of a fix? |
I added a test for this issue #260. I guess this issue can be closed. |
Hello,
Apologies if this just is a complete duplicate of #161 , I have read it, but admittedly not digested it, but maybe one aspect that wasn't clear to me is that this blurb from the README.md
I seem to be having issues, where matching is based not on a chunk, but on substrings in a chunk.
Test Script
Router Output
Test Script Output
In particular the ids we use are UUIDs, and it seems that when the UUID begins with the letter a, it essentially can't find the route anymore.
If I remove any of the following routes then the
/api/users/a766c023-34ec-40d2-923c-e8259a28d2c5
route is 200./api/users/award_winners
/api/users/admins
/api/:resourceType/foo
My read of the readme says that it we should match and consumer,
api
and then match and consumeusers
greedly, then it should simply have the choice between {award_winners, admins, :id}, and award_winners and admins should take priority, then both UUIDs should resolve to :id.I'm involved in updating a restify service that has hundreds of routes to a newer version that is based on find-my-way. I guess my general concern is that I don't understand the rules that find-my-way is using to resolve routes, and it seems very brittle, where adding a route anywhere in our platform may subtly break another route and it may break another route based only on some subset of values. I don't even know at this point what to explain to devs in terms of how to think about what the algorithm is doing.
The text was updated successfully, but these errors were encountered: