/user/info and /user/avatar hang for 75s when number is a phone number
维护者通常 1 天内回复
评估
调研方向
从 utils.ParseJID 和 utils.CreateJID 开始，然后检查 send_service.go 中去除 + 的部分，issue 中说明发送功能已经正常工作。检查 /user/info 和 /user/avatar 是否通过 ParseJID 解析 number，并确认 + 能够传递到 JID.User。在 ParseJID 中为 s.whatsapp.net 从 JID.User 删除 +，并更新 TestParseJID。完成标准是两个接口对电话号码都能快速返回，IsOnWhatsApp 仍然接收到 +，且测试全部通过。开始之前，请先确认作者提到的 PR 中是否已经包含这项工作。
由索引模型根据 Issue 内容生成。
描述
Description
POST /user/info and POST /user/avatar time out when number is a plain phone number (5511999999999 or +5511999999999). The request blocks until the IQ timeout (~75s) and returns 500 with info query timed out.
The same contact passed as a full JID ([email protected]) answers in well under a second.
Steps to reproduce
- Connect an instance.
POST /user/infowith{"number": ["5511999999999"]}→ 500 after ~75s (failed to send usync query: info query timed out).POST /user/avatarwith{"number": "5511999999999"}→ 500 after ~75s (info query timed out).- Repeat with
[email protected]→ 200 in ~0.3s.
Cause
utils.CreateJID returns +<number>@s.whatsapp.net. The + is intended for IsOnWhatsApp, but utils.ParseJID passes that string to types.ParseJID, so the + ends up in JID.User. The log shows the request going to [email protected], and WhatsApp never answers queries for that JID.
Sending messages works because send_service.go strips the + from the recipient right before SendMessage. Other code paths that use ParseJID don't.
Proposed fix
Strip the + from JID.User in utils.ParseJID when the server is s.whatsapp.net. CreateJID stays unchanged, so IsOnWhatsApp still gets the +. TestParseJID currently expects the + in the output and needs to be updated.
Possibly the same root cause as #28: /message/react also resolves number with ParseJID, and /send/text worked there because of the strip in send_service.go. I only tested /user/info and /user/avatar.
I have a PR ready for this.
Environment
- Evolution GO develop @ 7f79240
- 主要语言
- Go
- 星标
- 971
- 派生
- 519
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 没有贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
evolution-foundation/evolution-go 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 84/100
evolution-foundation/evolution-go#193 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 76/100
evolution-foundation/evolution-go#104 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 74/100
evolution-foundation/evolution-go#101 ·
维护者通常 1 天内回复
-
POST /group/participant always returns 400 "participants is required and cannot be empty" (wrong validation middleware on route)可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭bug
难度 1/5 1 小时以内 新手友好度 88/100
evolution-foundation/evolution-go#97 · 2 条评论 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 35/100
evolution-foundation/evolution-go#236 ·
维护者通常 1 天内回复
查看 evolution-foundation/evolution-go 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 72/100
masahitojp/mariamem#108 ·
维护者通常 1 天内回复
-
[Bug] Pod detail shows CPU usage ten times too high, and throws on decimal memory suffixes可能已有人在做 @RaphaelFakhri 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 84/100
维护者通常 11 天内回复
-
tsuru_app_cname and tsuru_app_router don't handle removal outside terraform可能已有人在做 @lbarrosby 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 82/100
-
contributor-friendly good-first-issue lang:go
难度 2/5 1-3 小时 新手友好度 82/100
irbis-sh/zen-desktop#870 · 1 条评论 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 1 天内回复