#general
Sharing something that might help new contributors, I faced while setting up archestra👇
Large repos can get really slow (clone, fetch, etc.), especially as they grow over time (Well-Architected)
I wrote a guide on how to handle this better while contributing:
Hope this helps someone getting started 🙌
🙌3
New release! 🚀🚀🚀
1.2.19 (2026-04-20)
Features
- add asana knowledge connector (#3922) (8d4bcbe)
- add fullscreen functionality to prompt input (#3461) (25106b5)
- add linear knowledge connector (#3766) (25e28f6)
Bug Fixes
- *chat:* add copy button to code blocks in conversation artifacts (#3868) (41c1612)
- enforce SSO allowed email domains (#3976) (22d2743)
- preserve native Slack markdown replies (#3936) (80010ae)
- *sharepoint:* recursive subfolder traversal via folder-traversal utility (#3960) (081d0b2)
Miscellaneous Chores
Hi everyone! I applied for the Software Engineer role and started going through the repo and I’d love to contribute. I noticed a lot of issues seem pre-scoped for candidates already in the pipeline – would you prefer I wait for a task through the process, or is it okay to pick something up independently?
Hi, I’m working on an issue approval flow for ChatOps, and I have a couple of questions:
1. When an approval request appears in a Slack thread, can only the user who initiated it approve or deny it, or can any user who has access to the bot do so?
2. If two users are talking to the bot in the same Slack thread and one of them receives an approval request, should a message from the second user interrupt the approval flow, or should it not?
Read-only live mirror of Archestra.AI Slack
👋Join the discussion withAI enthusiasts!Hi everyone! I applied for the Software Engineer role and started going through the repo and I’d love to contribute. I noticed a lot of issues seem pre-scoped for candidates already in the pipeline – would you prefer I wait for a task through the process, or is it okay to pick something up independently?
11 replies
Hi! You're right that the pre-scoped issues are reserved for candidates after a first call with us. However, there is no harm in picking something up except these issues in the meantime 🙂
Per Claude Code's deliberate analysis, it seems like there are only a few PRs. Would you mind me taking https://github.com/archestra-ai/archestra/issues/3219?
@user @user I'd like to ask a quick question if you don't mind 🙂 The following is referring to OpenAI API, but is true for other providers as well.
Looking at the logs, the original OpenAI error arrives at the proxy with all the right info:
"type": "invalid_request_error", "code": "context_length_exceeded"But by the time the AI SDK sees it, the proxy has re-wrapped it via handleError -> new ApiError(400, message), which Fastify serializes as:
"
type": "api_validation_error" // code field is goneMy current fix detects this by parsing the message text for "maximum context length" – which works but is fragile and couples us to provider's exact wording.
The cleaner fix in my opinion is upstream:
handleError in llm-proxy-helpers.ts should pass the provider's original response body through instead of re-wrapping it. That way mapProviderError can use the already-existing context_length_exceeded code check and we don't need message parsing at all.I wanted to check if there's a reason handleError re-wraps the body before touching it, since it's a pretty important piece of code
Could we add additional "internalcode" field to
APIError to indicate that it's an contextlength_exceeded error?And have a mapping of our own error codes?
0 - context_length_exceeded, .....WDYT?
@user I totally agree. Although, how do you feel about being a bit more verbose and use string values for our own error codes, instead of integers?
Could you clarify where AI SDK sees the error? On the frontend or backend?
Anyway, I don't have a strong opinion here, it's nit for now
On backend
@user would you mind having a look – https://github.com/archestra-ai/archestra/pull/3988?
Looking!