Server breaks when empty string provided for tags in {set}

[dilshans2k]

---

Subject of the issue

I was trying to find some way to delete all tags(just for curosity) and came across this bug.

Your environment

Server-side

• web.tinode.co, api.tinode.co
• sandbox.tinode.co
• Your own setup:
  • Platform - Linux
  • v0.19.3
  • MongoDB Backend
  • standalone

Client-side

• Your own client. Describe it:
  • Transport Websocket
  • Software Postman

Steps to reproduce

Send {hi} message, Login with any user, {sub} to me topic, Send this following message
{ "set":{ "id":"221122", "topic":"me", "what":"tags", "tags":[ "" ] } }

Expected behaviour

Error needs to handled inside the code if tags has some length but contain nothing.

Actual behaviour

Server breaks with the following error

Server-side log

I2022/07/27 05:45:11 in: '{
"set":{
"id":"221122",
"what":"tags",
"topic":"me",
"tags":[
""
]
}
}' sid='nxctsFDwwZU' uid='kY6n9p2ozDk'
panic: runtime error: index out of range [0] with length 0

goroutine 85 [running]:
main.normalizeTags({0xc000156540, 0xffffffffffffffff?, 0x4})
/app/files/src/github.com/tinode/chat/server/utils.go:90 +0x415
main.(*Topic).replySetTags(0xc0009b2180, 0xc0000cc580, 0x39cca89df6a78e91, 0xc0008ec270)
/app/files/src/github.com/tinode/chat/server/topic.go:2677 +0x4b3
main.(*Topic).handleMetaSet(0xc0009b2180, 0xc0008ec270, 0xc0009e3e86?, 0xa0?, 0xc0009e3f40?)
/app/files/src/github.com/tinode/chat/server/topic.go:372 +0x249
main.(*Topic).handleMeta(0xc0009b2180, 0xc0008ec270)
/app/files/src/github.com/tinode/chat/server/topic.go:420 +0x10c
main.(*Topic).runLocal(0xc0009b2180, 0xab58d7?)
/app/files/src/github.com/tinode/chat/server/topic.go:527 +0x42d
main.(*Topic).run(0xc0000481e8?, 0xc000223900?)
/app/files/src/github.com/tinode/chat/server/topic.go:205 +0x2c
created by main.topicInit
/app/files/src/github.com/tinode/chat/server/init_topic.go:131 +0x913

Client-side log

Log from Postman
Disconnected from ws://localhost:6060/v0/channels?apikey=AQEAAAABAAD_rAp4DJh05a1HAwFT3A6K

[or-else]

Fixed in 0d317b3. Thanks!