"Create a connection" button stuck on "Creating a connection..." - IMAP connection modal never opens

Questions
,
1

:bullseye: What is your goal?

Add a new IMAP connection to an Email module (watching a Yahoo Mail inbox) so a scenario can log incoming emails to a Google Sheet.

:thinking: What is the problem & what have you tried?

In the Email (IMAP) module, clicking “Create a connection” (type “Other IMAP”) makes the button switch to “Creating a connection…” and it stays stuck like that forever. No connection-type selection modal and no server/port/username/password form ever appears, so the connection can never be completed.

Already tried, with the same result every time:

  • Reloading the page
  • Opening the module in full-screen mode
  • Closing/reopening the Maia AI assistant chat panel
  • Deleting and recreating the module via Maia
  • Clearing localStorage and sessionStorage and reloading
  • Testing in a different browser / incognito window

Diagnostics: in the network tab, the request to /api/v2/imt-forms/connections/create (type=imap) returns HTTP 200 every time, but the UI never renders the resulting modal - looks like a frontend rendering bug, not a backend/permissions issue. status.make.com shows all systems operational, so it does not seem to be a platform-wide outage.

I could not complete a ticket through the official support form either - the reCAPTCHA kept expiring and the widget itself became unresponsive after a few attempts - so I’m posting here too. Has anyone else run into this, or is there a known workaround?

[PT-BR] No modulo de E-mail (IMAP), ao clicar em “Criar uma conexao” (tipo “Other IMAP”), o botao muda para “Criando uma conexao…” e fica travado assim indefinidamente. Nenhum modal de selecao do tipo de conexao nem formulario de servidor/porta/usuario/senha chega a aparecer.

Ja tentei, com o mesmo resultado todas as vezes:

  • Recarregar a pagina
  • Abrir o modulo em tela cheia
  • Fechar/reabrir o painel de chat da Maia
  • Excluir e recriar o modulo via Maia
  • Limpar localStorage e sessionStorage e recarregar
  • Testar em outro navegador / janela anonima

Diagnostico: na aba de rede, a requisicao para /api/v2/imt-forms/connections/create (type=imap) retorna HTTP 200 todas as vezes, mas a interface nunca renderiza o modal resultante - parece ser um bug de renderizacao no frontend, nao um problema de backend/permissoes. O status.make.com mostra tudo operacional, entao nao parece ser uma instabilidade geral da plataforma.

Tambem nao consegui concluir um chamado pelo formulario oficial de suporte - o reCAPTCHA ficava expirando e o proprio widget parou de responder apos algumas tentativas - por isso tambem estou publicando aqui. Alguem mais passou por isso, ou existe alguma solucao conhecida?

2

Your diagnosis looks right - 200 on the create call with no modal rendered is a front-end problem, not permissions. Two things that should get you moving.

Workaround: build the connection outside the module. Go to the left sidebar > Connections > Add, and pick Email (IMAP) there. That page uses a different render path from the in-module connection dialog, so it usually still works when the module popup is stuck. Once the connection exists it appears in the module’s dropdown and you never have to open that dialog. The same trick works when any connection modal hangs.

The thing that will bite you next: Yahoo. Yahoo has not accepted account passwords over IMAP for a while - a normal password fails authentication even when host and port are right. You need an app password: Yahoo Account Info > Account Security > Generate app password, then use that string as the IMAP password. Settings are imap.mail.yahoo.com, port 993, SSL/TLS on, username the full address. Worth generating it before you retry, so you are not debugging two problems at once and blaming the wrong one.

If the Connections page also hangs, that narrows it usefully - it would point at something in the browser rather than one broken dialog, and the usual culprit is an extension blocking a script (uBlock, Privacy Badger, a corporate proxy). You said incognito failed too, but extensions often still run there unless explicitly disabled, so worth checking that setting rather than trusting incognito.

On the support form: the reCAPTCHA expiring repeatedly is usually the same extension or strict cookie blocking. Emailing support directly, rather than using the form, sidesteps it.

Kane - Northpeak Automation