fix(skills): publish stored skill drafts from storage snapshots - #23032

🌐 Web query:

For the Node.js version declared by this repository, does Buffer.from(input, 'base64') reject malformed Base64 input or decode it permissively? Use the matching official Node.js Buffer documentation.

💡 Result:

For the Node.js versions current as of September 2026, Buffer.from(input, 'base64') does not reject malformed Base64 input. Instead, it processes the input permissively [1][2]. According to the official Node.js Buffer documentation, the 'base64' encoding assumes valid input [3][4][5]. When encountering a string that contains non-base64 data, the implementation does not throw an error; rather, it ignores certain characters (such as whitespace, which includes spaces, tabs, and new lines) and may effectively treat other invalid characters as if they were not present or were part of a different valid encoding sequence [3][6]. Because the method assumes the input is valid, it does not perform strict validation [3][5]. Consequently, providing malformed input will typically result in the creation of a Buffer containing whatever bytes could be decoded, or potentially ignoring the "garbage" input entirely without notification [1][2]. For robust applications where input validation is required, the documentation implies that developers should validate the Base64 input independently before passing it to Buffer.from [2].

Citations:

• 1: GitHub pull request 12012 in nodejs/node (link omitted to avoid creating a cross-reference)
• 2: https://stackoverflow.com/questions/60628066/nodejs-buffer-from-returns-invalid-value
• 3: https://nodejs.org/api/buffer.html
• 4: https://nodejs.org/docs/latest/api/buffer.html
• 5: https://nodejs.org/docs/latest-v26.x/api/buffer.html
• 6: https://github.com/nodejs/node/blob/main/doc/api/buffer.md

🏁 Script executed:

#!/bin/bash
printf '%s\n' '--- diff ---'
git diff -- packages/core/src/workspace/skills/publish.ts
printf '%s\n' '--- publish context ---'
sed -n '230,320p' packages/core/src/workspace/skills/publish.ts
printf '%s\n' '--- package runtime declarations ---'
rg -n '"engines"|"node"|node-version|setup-node' package.json packages/core/package.json .nvmrc .node-version .github 2>/dev/null | head -80
printf '%s\n' '--- relevant callers and types ---'
rg -n -A8 -B8 'Buffer\.from\(node\.content|StorageSkillFileNode|publishSkillFromFiles|buildPublishResultFromWalkedFiles' packages/core/src/workspace/skills

Repository: mastra-ai/mastra

Length of output: 23538

🌐 Web query:

For Zod 3.25.0, confirm that z.string().min(1).optional() permits undefined but rejects an empty string.

💡 Result:

In Zod 3.25.0, the schema z.string().min(1).optional() permits undefined but rejects an empty string ("") [1][2][3]. This behavior occurs because Zod treats .optional() as a modifier that specifically allows undefined (and missing keys in object contexts) [4][5][1]. It does not modify the underlying validation logic of the inner schema [6]. Since z.string().min(1) explicitly requires a string to have a length of at least one character, an empty string—which has a length of zero—is invalid and will be rejected [1][2][7]. If you need to permit both undefined and an empty string, you must explicitly account for the empty string in your schema definition, typically by using a union or transformation [8][9][6]. Common approaches include: 1. Using a union with z.literal(""): z.string().min(1).or(z.literal("")).optional() [8][9][6] 2. Using .transform() to convert empty strings to undefined before validation: z.string().transform((val) => val === "" ? undefined : val).optional() [8][1][2]

Citations:

• 1: https://checkyourvibe.dev/blog/how-to/zod-validation
• 2: GitHub issue 1821 in tambo-ai/tambo (link omitted to avoid creating a cross-reference)
• 3: GitHub issue 3532 in colinhacks/zod (link omitted to avoid creating a cross-reference)
• 4: https://zod.dev/api
• 5: https://github.com/colinhacks/zod/blob/9575cfecbabeb149a4991f931cf24f685ea8c55e/README.md
• 6: GitHub discussion 2780 in colinhacks/zod (link omitted to avoid creating a cross-reference)
• 7: GitHub discussion 2874 in colinhacks/zod (link omitted to avoid creating a cross-reference)
• 8: https://stackoverflow.com/questions/73582246/zod-schema-how-to-make-a-field-optional-or-have-a-minimum-string-contraint
• 9: GitHub discussion 553 in colinhacks/zod (link omitted to avoid creating a cross-reference)

🏁 Script executed:

sed -n '180,250p' packages/server/src/server/schemas/stored-skills.ts
printf '\n-- related schema references --\n'
rg -n "publishStoredSkillBodySchema|skillPath|versionId" packages/server/src/server -g '*.ts' | head -80

Repository: mastra-ai/mastra

Length of output: 12536

🤖 get_repo_knowledge executed:

get_repo_knowledge mastra-ai/mastra /tmp/coderabbit-repo-knowledge/mastra-ai-mastra-db814e7b/conventions /tmp/coderabbit-repo-knowledge/mastra-ai-mastra-db814e7b/architecture /tmp/coderabbit-repo-knowledge/mastra-ai-mastra-db814e7b/learnings

Length of output: 47778

🏁 Script executed:

rg -n -C 8 "publishStoredSkillBodySchema|publishStoredSkill" packages/server/src -g '*.ts'

Repository: mastra-ai/mastra

Length of output: 6515

🏁 Script executed:

sed -n '563,660p' packages/server/src/server/handlers/stored-skills.ts

Repository: mastra-ai/mastra

Length of output: 4257

🏁 Script executed:

sed -n '640,735p' packages/server/src/server/handlers/stored-skills.ts
printf '\n-- route body parsing contract --\n'
rg -n -C 6 "bodySchema.*safeParse|bodySchema.*parse|route\\.bodySchema|bodySchema" packages/server/src/server/server-adapter packages/server/src/server -g '*.ts' | head -120

Repository: mastra-ai/mastra

Length of output: 14787