Trying to understand a basic Phoenix Application and it's MVC model explained by a flowchart/statechart

Hello there,

I’m just starting with Elixir and Phoenix.

I’m wondering if I could understand the Phoenix “life cycle” correctly so far.
A “Traditional Phoenix Application” can be described simply as:

connection
|> endpoint()
|> router()
|> pipeline()
|> controller()

I like very much the simplicity of how the book use the Elixir pipelining to explain the application flow, the code is really very well documented by itself and you don’t really need flowcharts to explain the framework.

This part is quite verbose, I’ll describe the way how I understood each “part” of the Phoenix Framework and how it uses the MVC design pattern.

Migrations → defines a table structure for a database, here you can create a table, add fields and unique indexes.
Schema → create a data structure related to a table (defined on migrations), and define functions for validations using a “changeset”.
Context → a context uses a schema and Repo to define functions and pipelines to transform and persist data.
Controller → the controller will access the context asking for functions and pipelines, and will ask view to render the correct related page.
View → defines specific functions for parsing and filtering data to be used from a Template, and will render a specified Template.
Template → the actual HTML code and front-end logic.
Router → receive request and select correct controller.

MVC → Model = Schema+Context, View = View+Template, Controller = Router+Controller

I’m trying to make it a bit more clear to me trying to have an overview by using a State Diagram.
I’m not experienced in writing State Diagrams, so we can try to just interpret it abstractly?
(I’m open to any corrections and tips about it)
But as I have to learn how to use State Diagrams for my current job, I’ll try to explain the app flow using it.

New users can’t upload images, so I’ll have to upload it in a third party service. You might need to click the image to see it clearly.
https://imgur.com/a/YiIaj1x

Is it correct?
Could I say that those “steps” (states) of endpoint, router and pipeline can propagate an “error” input (the application state, in this case the “connection” data structure), and so, we end in a software “Error state”, propagating the conn down the pipelining, that will end in the “View” layer?

I didn’t connected the “Controller state” in the “Error state”, but the “conn” could propagate errors on this state as well, like form validation errors… changeset. Maybe I should have connected this transition.

But my main question, apart from the overall understanding is, it’s correct to interpret the “application flow” like this? Could I say that errors occurring in the endpoint, router and pipeline will end to be rendered in the View layer as well?

Because if I hit the wrong endpoint, if I request the wrong route, or if there is any validation problem during the proper pipeline (browser/api/other), Phoenix will render a special error template to reflect that as well, so we hit the View layer without hitting “our” Controller, right?

Sorry if this reasoning is plain wrong and sounds confusing.
I do am confused and I’m quite a beginner using MVC.