matthieuchabert
Hey 
We use allow_upload/3 in an handle_event/3 function like so:
def handle_event("open_modal", params, socket) do
socket =
socket
|> assign(:uploads, %{})
|> allow_upload(:image, [...])
[...]
{:noreply, socket}
end
It works fine when the event open_modal is triggered once but if it triggers again we get an issue:
(RuntimeError) existing upload for image already allowed in another component ()
This is raised by Phoenix.LiveView.Channel.ensure_unique_upload_name!/2 which checks if the upload name - here image - is unique.
In our case we can’t change that name to fix the issue and we’d like to reset that name unfortunately it isn’t stored in the socket assigns but in the Channel state which isn’t easily accessible from the Liveview.
Do you have any idea how we can solve this ?
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Bringing learning, work and compliance together since 1987.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixir-ls
- #elixirconf-us
- #ai
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Master modern tools, write cleaner code, and tackle real-world challenges.
Producing high quality Elixir screencasts since 2017.
Enabling companies to succeed by building software people love.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
romenigld
maybe with the handle_params function.
cblavier
I don’t think
handle_eventis the culprit nor thathandle_paramswould solve this.I also faced this issue where I want to do mass input and submit the same form multiple times to create multiple entries and I could not find the way to properly reset the uploader. It’s like some lingering state is still existing in the LiveView process, despite reassigning
:uploadsor callingdisallow_upload.If someone has any clue, I would also be interested
trisolaran
Can you please explain a bit better what you’re trying to achieve? Why do you need to “reset” the upload?
If I want to allow the user to submit multiple files with the same upload, I do that by setting
auto_upload: trueand handle all new uploads in theprogresscallback. Don’t know if this is related to what you guys want to do.mcrumm
I can confirm– in short, you can invoke disallow_upload/2 after allow_upload/3 to disable uploading, but if you then invoke allow_upload/3 again with the same name we raise.
So at the moment there really is no way to “reset” a specific upload name, but I also can’t recall whether we intended this or not, so it might be a bug
cblavier
Thanks! Do you know who might recall?
mcrumm
Chris might remember– feel free to open an issue to get more feedback!
matthieuchabert
We needed to “reset” the upload because the Liveview that handles the upload can invoke
disallow_upload/2andallow_upload/3multiple times in a row (inhandle_event/3when a user opens/closes a modal). This isn’t the same thing as allowing multiple file upload.As @mcrumm said:
We decided to put back
allow_upload/3in themount/3function and change dynamically theentry_pathbased on the socket assigns which is what we tried to achieve in the beginning.It’s worth investigating anyway so we may open an issue
Thanks for your help
benwilson512
Is this a stateful or stateless component? I’m pretty sure that if you’re gonna have a component handle uploads the component needs to be stateful, and then with a unique ID in each case. This would avoid some of the issues I think?
EDIT: Specifically the idea in that case is that if you need to “reset” an upload you simply replace the whole component with a new instance of the stateful live component with a new unique ID
matthieuchabert
I edited my last answer for more clarity:
It’s a Liveview not a LiveComponent so no re-render
hurricanebilly
The fix I went with was preserving the existing upload instead of recreating it – to the original poster, add a check to see if the upload is already created, and then don’t call
allow_uploadagain if the upload already exists