For example, in the following case
######
#...##
#[][]#
#.[].#
#.@..#
######
^
In this case, I try to push the box on the 4th row upward, which in requires pushing the left box on the 3rd row upward (ok), then the right box on the 3rd row upward (failed). In traditional programming language, you need to pull back the left box (backtracking), but in Elixir, you just need to use the state before pushing.
This was fun, like playing a game. But I’m not getting the right answer for part 2 even though the test passes. I watched the animation for half an hour and couldn’t see a mistake. 
Guess I’ll have to try another approach. @Aetherus gave me an idea not to store dots. I’m missing a step in my approach where I don’t look for simplification before I begin. 
Also and again: I hate when the example passes but input doesn’t. I feel AoC could be better if they provided more examples with all possible edge cases, so that if you’re able to pass them you practically know it will work for real input. They could provide another file with just examples and solutions. Because debugging on real input is tedious to say the least.
I think he wants you to find the edge cases by yourself ! Otherwise it would be just an optimization game..
Do you want to explain your approach so we can spot something missing ?
I have struggled so hard with this part2 that i have actually decided to stop doing new days until i have done this.
Several learnings.
Oh did i forget to say i should stop using AI?
touché
The thing is I “observed” the robot… must have missed another misbehaviour. I’m just complaining, this one is actually debuggable.
I’ll give it another go tomorrow, then if I give up, I’ll complain further. 
after stepping 2-300 moves through the mace (i skipped obstacle collisions and whitespace) i found this
####################
##[]..[]......[][]##
##[]...........[].##
##...........@[][]##
##..........[].[].##
##..##[]..[].[]...##
##...[]...[]..[]..##
##.....[]..[].[][]##
##........[]......##
####################
it can’t push four levels of boxes down 
New test case … its in cases i like this i just «of course»
Finally solved it today. Simplifying the problem (not storing robot or empty spaces) definitely helped in figuring out the recursive part for part 2. Made it easier to reason, not worrying about unnecessary stuff and also made it less bug prone. I got to stop going head first. 
defmodule Aoc2024.Solutions.Y24.Day15 do
alias AoC.Input
@start if Mix.env() == :test, do: {4, 4}, else: {24, 24}
@start_2 if Mix.env() == :test, do: {4, 8}, else: {24, 48}
def parse(input, part) do
[map, input] = input |> Input.read!() |> String.split("\n\n")
{parse_map(map, part), parse_input(input)}
end
def part_one({map, input}) do
input
|> Enum.reduce({@start, map}, &move_robot(&2, &1))
|> elem(1)
|> Map.to_list()
|> Enum.filter(fn {{_x, _y}, e} -> e == "O" end)
|> Enum.reduce(0, fn {{x, y}, _}, acc ->
acc + x * 100 + y
end)
end
def part_two({map, input}) do
input
|> Enum.reduce({@start_2, map}, &move_robot(&2, &1))
|> elem(1)
|> Map.to_list()
|> Enum.filter(fn {{_x, _y}, e} -> e == "[" end)
|> Enum.reduce(0, fn {{x, y}, _}, acc ->
acc + x * 100 + y
end)
end
defp next_position({x, y}, symbol) do
case symbol do
">" -> {x, y + 1}
"<" -> {x, y - 1}
"v" -> {x + 1, y}
"^" -> {x - 1, y}
end
end
defp move_robot({position, map}, symbol) do
case check_boxes(position, symbol, map, []) do
{:error, :unmovable} -> {position, map}
{:ok, boxes} -> {next_position(position, symbol), update_map(map, boxes, symbol)}
end
end
defp check_boxes(position, symbol, map, acc) do
{x, y} = next_position = next_position(position, symbol)
case Map.get(map, next_position) do
nil -> {:ok, acc}
"O" -> check_boxes(next_position, symbol, map, [next_position | acc])
"[" -> check_pboxes({x, y}, {x, y + 1}, symbol, map, acc)
"]" -> check_pboxes({x, y}, {x, y - 1}, symbol, map, acc)
"#" -> {:error, :unmovable}
end
end
defp check_pboxes(position, pposition, symbol, map, acc) when symbol in ["^", "v"] do
with {:ok, acc_right} <- check_boxes(position, symbol, map, [position | acc]),
{:ok, acc} <- check_boxes(pposition, symbol, map, [pposition | acc_right]) do
{:ok, Enum.uniq(acc)}
end
end
defp check_pboxes(position, _pposition, symbol, map, acc) do
check_boxes(position, symbol, map, [position | acc])
end
defp update_map(map, boxes, symbol) do
Enum.reduce(boxes, map, fn box_position, map ->
{box, map} = Map.pop!(map, box_position)
next_position = next_position(box_position, symbol)
Map.put(map, next_position, box)
end)
end
defp parse_input(input) do
input
|> String.split("\n")
|> Enum.reduce([], fn line, acc ->
Enum.reduce(String.codepoints(line), acc, fn e, acc -> [e | acc] end)
end)
|> Enum.reverse()
end
defp parse_map(map, part) do
map
|> String.split("\n")
|> Stream.with_index()
|> Enum.reduce(%{}, fn {line, x}, acc ->
line
|> String.codepoints()
|> maybe_expand(part)
|> Stream.with_index()
|> Enum.reduce(acc, fn
{e, _y}, acc when e in [".", "@"] -> acc
{e, y}, acc -> Map.put(acc, {x, y}, e)
end)
end)
end
defp maybe_expand(list, :part_one), do: list
defp maybe_expand(list, :part_two) do
list
|> Enum.map(fn
"#" -> ["#", "#"]
"O" -> ["[", "]"]
"." -> [".", "."]
"@" -> ["@", "."]
end)
|> List.flatten()
end
end
me too! finally! it feels so good . .and ill never touch that code again .. until next year …
my solution is a nested mess of recursive functions .. but it works no mutability .. uni directional data flow <3
https://github.com/jarlah/advent_of_code/blob/master/solutions/2024/day_15/lib/Part2.ex
in my solution i simulate/test movement before i move . so its easy to debug
Solution for Part A . Swapping only if value is “O” or “.”
https://github.com/RuthraiahThulasi/advent-of-code/blob/main/day15/AOC_2024-Day15-Part-A.livemd