FedWiki and Discourse are built into the console instead of connecting through the published contract #174
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: wiki-cafe/member-console#174
Reference in New Issue
Block a user
What a person cannot do today
Connect FedWiki or Discourse the way any other application would. FedWiki needs code on both sides, the farm plugin and
internal/integrations/fedwiki, which have to agree; Discourse's code lives in the console; and each keeps its own schema in the console's database. A newcomer has no worked example of the contract and no way to test a connector of their own.What they should be able to do
Why it matters
The contract is only credible if the project's own applications use it. Moving both before launch means a deployment sees connectors it can copy, and the
fedwikianddiscourseschemas leave the console's database;stripestays, because payments are not part of the contract (#80).Where
internal/integrations/fedwiki,internal/integrations/discourse, the farm plugin, the specification repository from #171, a harness and an example application.Done when
FedWiki and Discourse both run through the contract with no code under
internal/integrations; the conformance harness passes for both and for the example application; thefedwikianddiscourseschemas are retired; #46 is resolved with them.Order
Comes after #173; the last of the four, after #171 and #172.
The first candidate for the shared helpers is how FedWiki takes in a lifecycle request today, in
internal/integrations/fedwiki/web/requests.go: parsing the instance address, building the request, starting its workflow and answering a repeated request. Only the mapping from a request's answer to what the page shows is free of FedWiki specifics; the rest has to be separated first. The conformance harness is where each operation a connector declares meets its implementation.Two lessons for the shared helpers from how FedWiki answers a repeated request.
The JSON delete (
DeleteSiteininternal/integrations/fedwiki/web/api.go) answers a repeat from a second read of the request, taken after its recording commits and outside the instance lock, and it does not check whether that read found anything. When two identical deletes arrive together, the second is recorded as a repeat of the first. If the first request's workflow start is then refused, its unstarted row is deleted, the second request's read finds nothing, and it answers 200 with{"success":false,"status":""}. The JSON create reads again the same way and answers 409 when the row has gone. The recording's answer already carries the status, the reason and the workflow id, so a helper that answers repeats should answer from it, with no second read, and the protocol's answer should carry what a response needs.finishAllWith(internal/integrations/fedwiki/workflows/request_activities.go) restates in Go the rule thatFinishLifecycleRequeststates in SQL: a finished request with the same status and reason is a repeat, and anything else is not found. A connector helper for finishing a request should state it once.One of the temporary lint exemptions this issue owns is gone:
swapActiveSite(internal/integrations/fedwiki/web/site_actions.go) came down to the cognitive-complexity limit when its site checks moved into helpers, so its pinned rule in.golangci.ymlwas removed. The FedWiki create handler's rule (CreateSite, complexity 48) is the one left under this issue.Commit:
9767f9ac