Phoenix app sur la production plante et pas en développement

Question

J'ai une application Phoenix qui est en production en ce moment mais j'ai remarqué que chaque fois qu'une erreur survient, elle plante tout simplement l'application tout en développement, elle ne fonctionne pas. D'abord j'ai essayé de remplir toutes les erreurs mais ensuite je pensais que ce n'est pas comme ça Elixir/Erlang fonctionne, essayé en développement avec la même opération et l'erreur est seulement enregistrée une fois et les tâches écrasées sont redémarrées pendant ce temps fois et plante l'application entière. Je ne sais pas si c'est quelque chose avec ma config, c'est la config Endpoint que j'ai pour prod en ce moment.

config :appname, AppName.Web.Endpoint, 
    on_init: {AppName.Web.Endpoint, :load_from_system_env, []}, 
    cache_static_manifest: "priv/static/cache_manifest.json", 
    http: [port: {:system, "PORT"}], 
    url: [host: "localhost", port: {:system, "PORT"}], 
    root: ".", 
    debug_errors: false, 
    server: true, 
    code_reloader: false, 
    check_origin: false, 
    version: Mix.Project.config[:version], 
    secret_key_base: System.get_env("SECRET_KEY_BASE"), 
    watchers: [] 

Ce fichier est le dev.exs

config :appname, AppName.Web.Endpoint, 
    http: [port: 4000], 
    debug_errors: true, 
    code_reloader: true, 
    check_origin: false, 
    secret_key_base: "rFiGCabqtoBaPZUZLoGaRuhgbBkynQazMnI2dpxN4aQEJzyQx0J7beyU2AZ0yMYO", 
    watchers: [node: ["node_modules/brunch/bin/brunch", "watch", "--stdin", 
        cd: Path.expand("../assets", __DIR__)]] 

J'espère qu'il a quelque chose à voir avec config, il est un peu ennuyeux d'avoir à redémarrer l'application pour un minimum d'erreurs qui doivent être tout simplement éviter.

EDIT: Je viens de remarquer que l'application parfois plantage et parfois il ne pas, j'enregistrait les événements du terminal et a vu ceci:

(Postgrex.Error) ERROR 22001 (string_data_right_truncation): value too long for type character varying(255) 
    (ecto) lib/ecto/adapters/sql.ex:571: Ecto.Adapters.SQL.struct/7 
    (ecto) lib/ecto/repo/schema.ex:467: Ecto.Repo.Schema.apply/4 
    (ecto) lib/ecto/repo/schema.ex:276: anonymous fn/13 in Ecto.Repo.Schema.do_update/4 
    (euridime) lib/euridime/telegram/handlers/keyboard/keyboard.ex:331: Euridime.Keyboard.set_user_wallet/2 
    (euridime) lib/euridime/telegram/handlers/keyboard/keyboard.ex:136: Euridime.Keyboard.check_command/1 
    (elixir) lib/enum.ex:645: Enum."-each/2-lists^foreach/1-0-"/2 
    (elixir) lib/enum.ex:645: Enum.each/2 
    (euridime) lib/euridime/telegram/task.ex:9: Euridime.Task.pull_updates/1 
Function: &Euridime.Task.pull_updates/0 
    Args: [] 

post-scriptum C'est juste l'erreur qui s'est écrasée la dernière fois, étant lié à Postgres, il se bloque pour d'autres raisons aussi.

C'est l'erreur enregistrée plusieurs fois, parfois elle est simplement enregistrée une fois et évitée, alors pourquoi est-ce qu'elle plante ici au lieu d'être redémarrée? Je pense que ça recommence trop souvent, puis ça se bloque? Comment pourrais-je éviter cela?

EDIT 2: commencer rappel:

def start(_type, _args) do 
    import Supervisor.Spec 

    # Define workers and child supervisors to be supervised 
    children = [ 
     # Start the Ecto repository 
     supervisor(Euridime.Repo, []), 
     # Start the endpoint when the application starts 
     supervisor(Euridime.Web.Endpoint, []), 

     worker(Task, [Euridime.Task, :pull_updates, []], id: :pull_updates), 
     worker(Euridime.DETS, []), 
     worker(Euridime.Emailer, []), 
    ] 

    # Registry 
    gen = [ 
     worker(Euridime.Server, []), 
     worker(Euridime.Notify, [], restart: :transient), 
     worker(Euridime.PayService, [], restart: :transient) 
    ] 
    supervise(gen, strategy: :simple_one_for_one) 

    opts = [strategy: :one_for_one, name: Euridime.Supervisor] 
    Supervisor.start_link(children, opts) 
    end 

Answer 1

On dirait que j'ai eu quelques mauvaises stratégies sur l'arbre de surveillance, j'ai eu :one_for_one au lieu de :one_for_all qui était à l'origine des accidents, je ne suis pas sûr de l'explication technique au sujet quels processus ont dû être redémarrés pour que l'application ne plante pas. C'est résolu pour l'instant, je vais devoir continuer à tester ce comportement sur la production pour vérifier.