-
Notifications
You must be signed in to change notification settings - Fork 56
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
Question: is it possible to set compatibility_flags for wrangler.toml? #246
Comments
Hey @remihuigen When deploying with the You can see it in your Cloudflare Pages project: Could you verify? |
@atinux You are correct the flag is set indeed... Any other advice on how to resolve this issue? My guess is that this line of code is the culprit. unenv should support the usage of crypto in workers: https://github.com/unjs/unenv?tab=readme-ov-file#cloudflare |
I am wondering if Algolia SDK should not import from |
If you can enable compatibility flags for hub users, a quick way would be to use We can't do this automatically for Nitro users but working on a hybrid approach coming soon with unenv v2 / nitro v3 that fixes the issue. Otherwise indeed we have to kindly ask upstream libraries to explicitly avoid Node-speicific features. |
Opened algolia/api-clients-automation#3608, let's see if this will fix! |
Could you try the latest version of the algolia client @remihuigen ? |
okay, upgraded to 5.2.3 (was still using v4 previously). My endpoint now returns a different 500 error {
"message": "c.generateSecuredApiKey is not a function",
"statusCode": 500
} It's a bit hard to trace the issue, since I have no way to simulate a CF pages env locally, and in a regular dev env everything works just fine
for contextbasically, what I'm trying to achieve is that my endpoint // api/search/config.get.ts
export default defineEventHandler({
onRequest: [accessControlSearch],
handler: async (event) => {
const { refresh } = getQuery(event)
const { appId, privateKey } = useRuntimeConfig().algoliaSearch.onderwijsloket
const { session } = event.context
const indices = await getOwlIndices()
// Secured api key for user
// https://www.algolia.com/doc/api-reference/api-methods/generate-secured-api-key/#method-param-usertoken
const algolia = useSearch({session})
const {algoliaSecuredKeyStorage} = usePrefixedStorage()
if (refresh === 'true' || refresh === "1") {
await algoliaSecuredKeyStorage.removeItem(session.itemId)
}
let securedKey: AlgoliaSecuredKey | null = await algoliaSecuredKeyStorage.getItem(session.itemId)
// If in cache
if (securedKey) {
// Check if key is still valid
if (securedKey.apiKeyValidUntil > new Date().getTime()) {
return {
applicationId: appId,
apiKey: securedKey.apiKey,
apiKeyValidUntil: securedKey.apiKeyValidUntil,
indices
}
} else {
// Remove it from storage
await algoliaSecuredKeyStorage.removeItem(session.itemId)
}
}
const algolia = useSearch({session})
const validUntil = addDaysToDate(new Date(), 365).getTime()
const restrictions = {
userToken: session.itemId,
validUntil,
restrictIndices: indices
}
const generatedSecuredKey: string = algolia.generateSecuredApiKey(
{parentApiKey: privateKey, restrictions}
)
await algoliaSecuredKeyStorage.setItem(session.itemId, {
apiKey: generatedSecuredKey,
apiKeyValidUntil: validUntil
})
return {
applicationId: appId,
apiKey: generatedSecuredKey,
apiKeyValidUntil: validUntil,
indices
}
}
}) the useSearch utility return the algolia client (as per https://www.algolia.com/doc/libraries/javascript/v5/) |
I know the debugging experience right now is not best, could you check https://hub.nuxt.com/docs/recipes/debug ? |
Did some more digging. Found a couple of issues. First: my implementation of V5 was incorrect. After I fixed that I encountered a new error Apparently, the browser build from the algolia client is used in bundling in stead of the node build. Haven't figured out why though From
|
Would you mind creating an issue there? Maybe they have some hints about it |
Well, I'm back to where I started, which is With 5.4.0, the algolia client now resolves correctly to the node build. But it also reintroduced the issue with the crypto package. Which is weird, since this was resolved in 5.2.2 with the |
Let's try something:
Will use use the node compat which is up to 89,9% — https://workers-nodejs-compat-matrix.pages.dev/ |
with @nuxthub/core@0.7.9 and wrangler@3.73.0 |
Got this error locally (similar to #273). Just did a deploy, which failed after building worker chunks with
updated config to
which failed with
|
Same thing happened to me, did you find a solution @remihuigen ? |
Also setting |
Not yet. Upgrading the client to ^5.4.0 did resolve some worker runtime issues it had, but not this one. |
It seems to be a cloudflare issue, they say to create a new app 🤦 or manually deploy with https://community.cloudflare.com/t/pages-app-in-permanently-broken-state-due-to-wrangler-toml/708610/7 (not the same problem as not being able to run nodejs_compat_v2, I tried with a new app, did not work) |
Let me check this, they changed it without notice… |
|
@atinux is this though nuxthub or deployed through github? also what might affect |
Also just deployed on a new and clean cloudflare pages app, and got the same error:
Do I need to setup some account-wide config? Is maybe a build cache problem? maybe the bindings are creating the issue? |
I tried also with another app that I have not used/deployed for 3 months, this one is nuxt too, and its throwing the same error. |
You have to use |
@atinux seems to be a general problem where a subset of users are having this issue |
I guess, I'll wait for when it becomes GA on the 23rd. |
Damn, this is an issue in Cloudflare indeed, works only with |
Just came around to trying this, since we can now deploy with nodejs_compat_v2. But I'm still getting I'm now running into similar issues with the cloudinary node SDK. this one returns |
Could you please try by removing the |
same thing unfortunately...
|
Did you find a solution @remihuigen ? Having same issue |
@RakuThe1 unfortunately not |
Please make sure to do this in your export default defineNuxtConfig({
// ...
hub: {
// ...
bindings: {
compatibilityDate: '2024-10-21'
}
},
}) |
@atinux added the compatibilityDate to Upgrading @nuxthub/core from 0.7.20 to 0.7.34 also seems to break caching for some reason (for both functions and handlers) |
What is the error you have regarding caching? |
No errors are logged, but requests are no longer cached. Just rolled back to previous deploy (with core 0.7.20) and caching resumed. The actual code didnt change between the two deploys, i only updated their core package and set the compatibility date as per your suggestion. Haven't had the time yet to trace the cause though. Glanced over the changelog, but didn't see anything between 0.7.20 and 0.7.34 that was a clear cause. Any pointers as to what the issue might be? |
Actually the cache entries not use expiration ttl. What are you cache options? Do you use swr and what is the max age? |
I'm only caching server api handlers and function (mostly functions). MaxAge is one day for most functions, but varies. Haven't used swr anywhere. For example
|
I ran into this error:
[unenv] crypto.createHmac is not implemented yet!
using the algolia clientclient.generateSecuredApiKey()
method.Hmac should be available in workers if the
nodejs_compat
flag is set in wranger.toml, but I don't see a way to do this.Adding a wrangler.toml file to the root of my directory does nothing.
any suggestions on how to accomplish this? Thanks!
The text was updated successfully, but these errors were encountered: