grpc MessageType doesn't match with that in ts-wechaty

[wj-Mcat]

https://github.com/Chatie/grpc/blob/4c32075f391c29407a9ace0fb6c8765097277bb1/proto/wechaty/puppet/message.proto#L9-L26

This does not match the MessageType definition in wechaty-puppet, and we found this during testing. Tests show that wechaty-puppet's data type definition is correct.

export enum MessageType {
  Unknown = 0,

  Attachment,     // Attach(6),
  Audio,          // Audio(1), Voice(34)
  Contact,        // ShareCard(42)
  ChatHistory,    // ChatHistory(19)
  Emoticon,       // Sticker: Emoticon(15), Emoticon(47)
  Image,          // Img(2), Image(3)
  Text,           // Text(1)
  Location,       // Location(48)
  MiniProgram,    // MiniProgram(33)
  GroupNote,      // GroupNote(53)
  Transfer,       // Transfers(2000)
  RedEnvelope,    // RedEnvelopes(2001)
  Recalled,       // Recalled(10002)
  Url,            // Url(5)
  Video,          // Video(4), Video(43)
}

[wj-Mcat]

This leads to this problem in all multi-languages wechaty, not just in python-wechaty.

[huan]

Short answer:

1. They are never guaranteed to be the same value.
2. We must always be prepared that their values are not the same.

Long answer posted later shortly.

[huan]

Long answer:

The wechaty-puppet is the golden source of truth for all the child puppet classes (wechaty-puppet-xxx) as long as we are working in the TypeScript environment.

The situation will be changed when we are not working under the TypeScript environments:

1. the GRPC Service
2. the Multi-lang Wechaty (e.g. Python)

The GRPC Service

All the GRPC Service is based on the Protocol Buffer definition file, this file will define everything about the Puppet API and all the constraints (like MESSAGE_TYPE_ATTACHMENT)

When we are working with the GRPC service, we must map everything that we have from local to the Protocol Buffer defined values.

And as we discussed before, for a higher perspective of the Wechaty ecosystem, we will treat the Protocol Buffer values as the true Golden Source of Truth. (above all languages, including TS)

Maybe we should call our TypeScript Puppet Silver Source of Truth

The Multi-lang Wechaty

Multi-lang Wechaty means Python, Java, and Go (Non-TS) Wechaty.

When Multi-lang Wechaty is working with the GRPC Service, we should convert all values from the GRPC service to the local value, so that we can make sure everything is right.

As we discussed before, the best way to use those values for our Multi-lang Wechaty is that we do not define locally. Instead of locally define them, we use all defined values from the GRPC Stub file because they can be auto-generated from the Protocol Buffer, which will be always synced with our Golden Source of Truth: Protocol Buffer.

Summary

1. RPC Protocol Buffer is the Golden Truth of Source of the whole Wechaty ecosystem.
2. TS wechaty-puppet is the Silver Truth of Source (for TS only)

Convert everything from local to GRPC, then from GRPC to local. You can think what we are doing is as same as the socket API functions: htons(), htonl(), ntohs(), ntohl().

[wj-Mcat]

Yes, wechaty-puppet should be golden truth for all wechaty-puppet-*. I strongly agree with that.

The reason why I create this issu is that hostie-server follow ts-wechaty-puppet data structure. which may lead multi-language wechaty must complete the mapping process. The MessagPayload's MessageType from the hostie-server follow the truth of the ts-wechaty-puppet, so, I begin to think about that whether wechaty-puppet is the final Golden Truth, which may be modified at eariler stage. All multi-language wechaty is at early stage, so as the wechaty-puppet golden truth. This is my consideration.

And completing the mapping process is ok for us. After you explaination, I think we should try to keep the Golden Truth of the wechaty-puppet.

[huan]

Thanks for such a insightful analytics. I'll review the related code in details later.

[Edward-Zhou]

I am testing .net with Wechaty.Grpc nuget package, and I hit the similar issue that, the MessageType.MiniProgram in github.wechaty.grpc.puppet are not map the reponse.

For server response, it will return 9 for mini program, and the MessageType.MiniProgram in github.wechaty.grpc.puppet is 10.

In addition, sometimes it will return 0 for miniprogram.

I am test with wechaty-puppet-donut.