/email-sub doesn't match anything (unless you meant the last one to be /:c)

A PUT to /c doesn't invoke bar?

Sorry, was meant to be /c! Edited now. 🙂

And no, it doesn't.

🙂

hmm, doesn't match anything else

right? 😅

does it work w/ any other http verb? e.g., if you change it to :get ?

nope, same issue

:post too

so, really, you're saying a single component route with any http verb and any interceptor with an :enter never calls the enter fn?

the routes are a set, so order ostensibly doesn't matter

in the above case? yeah seems like it!

what's the output of expand-routes?

no reason to be coy about real names on reflection, ha...

({:path "/:page-uid/:slug",
  :method :get,
  :path-constraints {:page-uid "([^/]+)", :slug "([^/]+)"},
  :path-re #"/([^/]+)/([^/]+)",
  :path-parts [:page-uid :slug],
  :interceptors [#io.pedestal.interceptor.Interceptor{:name :get-pages,
                                                      :enter #object[carnun.com.server.interceptors$fn__44626 "0x32682328" "carnun.com.server.interceptors$fn__44626@32682328"],
                                                      :leave nil,
                                                      :error nil,
                                                      :carnun/doc "If the `single` query param is present, returns 'raw' page html for the URL's primary page. Otherwise,\n               returns html for all of the pages (primary + `pages`) wrapped in boilerplate — i.e. the full site."}],
  :route-name :get-pages,
  :path-params [:page-uid :slug]}
 {:path "/email-sub",
  :method :put,
  :path-re #"/\Qemail-sub\E",
  :path-parts ["email-sub"],
  :interceptors [#io.pedestal.interceptor.Interceptor{:name :upsert-sub, :enter #object[carnun.com.server.interceptors$fn__44629 "0x6f35f49" "carnun.com.server.interceptors$fn__44629@6f35f49"], :leave nil, :error nil}],
  :route-name :upsert-sub,
  :path-params []}
 {:path "/",
  :method :get,
  :path-re #"/\Q\E",
  :path-parts [""],
  :interceptors [#io.pedestal.interceptor.Interceptor{:name :redirect-home, :enter #object[carnun.com.server.interceptors$fn__44624 "0x106aac72" "carnun.com.server.interceptors$fn__44624@106aac72"], :leave nil, :error nil}],
  :route-name :redirect-home,
  :path-params []})

this one, I'm guessing:

{:path "/email-sub",
  :method :put,
  :path-re #"/\Qemail-sub\E",
  :path-parts ["email-sub"],
  :interceptors [#io.pedestal.interceptor.Interceptor{:name :upsert-sub, :enter #object[carnun.com.server.interceptors$fn__44629 "0x6f35f49" "carnun.com.server.interceptors$fn__44629@6f35f49"], :leave nil, :error nil}],
  :route-name :upsert-sub,
  :path-params []}

this weirdness holds with the redirect-home route omitted too, fwiw

and yes, that's the one

just ... bizarre

looking at a pedestal service of my own, I see no difference for a single component route

anything special about :upsert-sub ?

> just ... bizarre you can say that again

certainly not right now!

(def upsert-sub
  {:name :upsert-sub
   :enter (fn [ctx]
            (let [db (xt/db (get-in ctx path/xtdb-node))]
              (prn "foo")
              (def ctx ctx)
              #_(email/upsert-sub)
              ;; save contact to db
              ;; send confirmation email
              (assoc ctx :response {:status 200
                                    :body "yo"
                                    :headers {"Content-Type" "text/plain"}})))})

The idea that :enter here never fires is based on never seeing the prn output and ctx remaining unbound, fwiw.

seems pretty solid

don't names have to be ns-qualified?

e.g. ::upsert-sub

hmm, that isn't an issue with the other routes/interceptors

but idk, you might be right!

I've never not qualified them, so I'm just going off of experience. Probably not an issue

:name should be optional

iirc they just have to be unique, which qualification increases the chances of 😛

possible you're throwing an exception from your xt/db call and then swallowing that exception?

can you move your prn and def to before the let ?

on it!

I'm ... out of ideas. 😄

well... it was worth a shot

no change

really appreciate the help regardless man 😄

please tell me what it was when you figure it out so I can share in the facepalming for whatever simple thing we both missed

oh, goes without saying

😁

goodluck!

ty!

btw, there is route constraints http://pedestal.io/guides/defining-routes#_constraints

Thanks for the suggestion @U2J4FRT2T! But I'm not sure where they'd come in here (given the below)... Do you have an idea? 🙂

*(given the below, and that I'm not landing on any other routes either 😕 )

cc: @U087E7EJW

from recommendations I was given years back around wild card routes and path params in pedestal it makes a lot of sense that it was having those problems (though been a while since I’ve read through the routers). where the /:page-uid/:slug is probably conflicting with the /email-sub route with them being at the same level, and the path param parsing of /:page-uid/:slug would interfere with the identification of the email-sub route. doing what you did and grouping the route for /:page-uid/:slug under some prefix, is the same recommendation I’d be giving people at work. the prefix for just the /blog/:page-uid/:slug route should be the only one needed. ran a few tests with a dummy pedestal-service template and things check out so far. looks like I’m more than a bit late to the convo (maybe you’ve already found the answer 🤷), though hopefully this helps someone in the future.

@UE4SAM0A0 I went with the prefixing, yep! 🙂

@U018D6NKRA4 cool 👍

I didn’t think of it at the time we last chatted, but there are also multiple routers with different routing semantics, see the table in this section of the docs: http://pedestal.io/reference/routing-quick-reference#_routers