Server 4401 ingest space feedback

[valeksiev]

Describe the background of your pull request

Fixes: #4401

[techsmyth]

Looks good!

Main concern is the linkage back from AI Server to VC, to be chatted through...

[valeksiev]

@techsmyth @hero101 We all dislike the dependency of the AiServer on the the VC repository (or some other part of the collaboration server), but I can't think of a way around it. This will need reworking when we split out the AiServer anyway.

Ignoring this I think I've addressed all comments and the implementation is complete.

[techsmyth]

Understood re linkage back from AI server to collaboration server. To be addressed later.

[ccanos]

Tested locally and it worked fine

• Latest server-4401-ingest-space-feedback on both client and server.
• Added AZURE_OPENAI_API_KEY=... to .env.docker
• Modified AUTH_ADMIN_EMAIL and AUTH_ADMIN_PASSWORD in .env.docker - careful with special characters, you'll need to escape the $ sign, and maybe put the password in between double quotes.
• Delete Exchange event-bus in RabbitMQ if the type is not direct. If the type is fanout get in, delete the exchange and restart services
• Set to null all the bodyOfKnowledgeLastUpdated cells in the table ai_persona_service - careful with MySQLWorkbench, if safe updates is enabled you need to include an id column in all the WHERE clauses.
• Navigate to http://localhost:3000/vc/<yourVC>/settings/settings
• See that the status says Initializing:
  
• Open browser console and look for the graphql WebSocket
  
• Click on the button Update Knowledge
• See the new message coming that updates the status
  
• See that in MySQL table ai_persona_service the VC's bodyOfKnowledgeLastUpdated column has been updated
• I don't see any errors in the server or in the services logs

[ccanos]

@valeksiev One note I just noticed, maybe it's okay, maybe you can't/don't want to do anything about it,
but the dates normally are stored in the database in UTC, and for the column bodyOfKnowledgeLastUpdated I have noticed it is storing current date as is. Or at least MySQLWorkbench is translating it to my timezone, not sure.