Good First Issues in Erlang

Since OTP29, there will be a warning when using the catch operator, which has been deprecated for a long time. It is recommended to instead use try…catch. Here is a list of locations, where only a catch ... is used (commit 75a77a7): src/proper/src/proper_statem.erl:770:46: Warning: 'catch ...' is deprecated; please use 'try ... catch ... end' instead. src/couch_epi/src/couch_epi_module_keeper.erl:59:5: Warning: 'catch ...' is deprecated; please use 'try ... catch ... end' instead. src/couch_epi/src/couch_epi_functions_gen.erl:343:10: Warning: 'catch ...' is deprecated; please use 'try ... catch ... end' instead. src/couch_epi/src/couch_epi_functions_gen.erl:352:6: Warning: 'catch ...' is deprecated; please use 'try ... catch ... end' instead. src/couch_log/src/couch_log_trunc_io.erl:99:10: Warning: 'catch ...' is deprecated; please use 'try ... catch ... end' instead. src/couch_log/src/couch_log_trunc_io_fmt.erl:291:10: Warning: 'catch ...' is deprecated; please use 'try ... catch ..

What happened? An MQTT 5 client connected over WebSocket (ws:// / wss://) with Session Expiry Interval = 0 (or absent, which means 0), and Will Delay Interval > 0 never gets its will message published when the connection is closed abnormally (TCP reset / process killed, i.e. no DISCONNECT packet and no WebSocket close frame). The same client over plain TCP (mqtt:// / mqtts://) gets the will message published immediately, as expected. Observed matrix (client killed with SIGKILL, subscriber waiting on the will topic): transport proto Session Expiry Will Delay will received ws 3.1.1 - - immediately ws 5 30 10 after 10 s ws 5 30 0 immediately ws 5 0 10 never ws 5 1 10 after 1 s ws 5 absent 10 never ws 5 0 0 immediately tcp 5 0 10 immediately tcp 5 absent 10 immediately Debug log for the failing case (ws, expiry 0, delay 10): msg: websocket_closed, reason: {error,sock_closed} msg: maybe_publish_will_msg_other_delay, reason: sock_closed msg: websocket_terminated

Describe the bug logger_h_common sends every 21st write synchronously. The synchronous log path in the file_ctrl_loop always does a file_check. See here. Expected behavior logger respects the file_check configuration and only does file_check once the interval has passed. Additional context Found this while tuning file_check in a real system and observing syscalls. I expected configuring file_check to heavily reduce the amount of times file_check is called, but on high throughput systems, it makes very little difference because the synchronous path behaviour. If intentional, I think this should be documented. If not, the fix is simply removing the ensure_file call from the sync log, since write_to_dev already conditionally calls ensure_file if the file_check window has passed.

Describe the bug ODBC_CAN_BUILD_DRIVER=true must be specified via an environment variable in order to compile odbcserver such that it gets installed with erlang/otp and thus can go into a release for an application. To Reproduce git checkout OTP-29.1.1 && git clean -xfd && ./configure --with-odbc && make -j && make release && f=$(find release -name odbcserver -print -quit) && [ -n "$f" ] && echo "FOUND : $f" || echo "ERROR: odbcserver not found" Observe "ERROR: odbcserver not found" Then : export ODBC_CAN_BUILD_DRIVER=true && git checkout OTP-29.1.1 && git clean -xfd && ./configure --with-odbc && make -j && make release && f=$(find release -name odbcserver -print -quit) && [ -n "$f" ] && echo "FOUND : $f" || echo "ERROR: odbcserver not found" Expected behavior When --with-odbc switch is given odbcserver is compiled and can be installed during the life time of OTP 29. Affected versions OTP >= 29.0 Additional context N/A

Describe the bug logger:remove_handler/1 can drop a different handler that was added at about the same time. The dropped handler keeps its config (logger:get_handler_config/1 answers {ok, _}), but it is gone from the primary handlers list, so its log/2 is never called. The cause is in lib/kernel/src/logger_server.erl, handle_call({remove_handler,HandlerId}, ...): {ok,Config} = logger_config:get(Tid,primary), Handlers0 = maps:get(handlers,Config,[]), Handlers = lists:delete(HandlerId,Handlers0), call_h_async( fun() -> call_h(Module,removing_handler,[HConfig],ok) end, fun(_Res) -> logger_config:set(Tid,primary,Config#{handlers=>Handlers}), logger_config:delete(Tid,HandlerId), ok end,From,State); Config and Handlers are read when the request arrives. When another async request is in flight, call_h_async/4 queues the two funs, and the post fun runs later with that stale Config. Any add_handler that completed in between is overwritten: the post fun of add

Since OTP 28 (PR #8962), prim_tty's raw mode no longer has a way to disable ISIG, IEXTEN and IXON. The interactive shell is unaffected (ctrl+c and ctrl+d work as before), but applications that read raw keystrokes cannot receive control bytes as data: ctrl+o (VDISCARD), ctrl+c (SIGINT) and ctrl+s/ctrl+q (XON/XOFF) are consumed by the terminal driver. OTP 26 had a sig option for this: sig => false cleared exactly those flags. PR #8962 dropped it during the options refactor, with no in-tree callers and no discussion. Third-party terminal UIs (IEx, Nerves, ...) lost the only way to get a full raw mode. Repro: erl on a pty shows lflag=0x4c3 (ISIG/IEXTEN on). Sending 0x0f (ctrl+o) - the application receives nothing. PR #11514 fixes this through the public shell:start_interactive/1 API: {noshell, #{mode => raw, signals => false}} disables ISIG/IEXTEN/IXON in raw mode (ENABLE_PROCESSED_INPUT on Windows), default true so shell behavior is unchanged. The option can be toggled at runtime.

Is your feature request related to a problem? Please describe. open_port/2 supports length-prefixed packets through {packet, N}, but packet-length headers are always big-endian. Erlang processes using a spawned program or an {fd, In, Out} port cannot select little- or native-endian framing. Callers that use non-big-endian protocols must fall back to {packet, raw} and implement framing themselves. This duplicates framing logic and prevents them from using the port's built-in packet handling. Describe the solution you'd like Allow callers to select the endianness of packet-length headers on spawned and file-descriptor ports. Existing {packet, N} behavior must remain compatible. The capability should support little- and native-endian headers and include documentation and tests for supported packet lengths. Its public API should align with related packet APIs where their abstractions match. Describe alternatives you've considered Using {packet, raw} allows callers to implement framing them

Describe the bug The URIs produced by EDoc's link resolver are not compatible with the on-line documentation. To Reproduce Configure the base URI for the on-line documentation: edoc_run application myapp . [{app_default, "https://www.erlang.org/doc/apps"}] Expected behavior Links of the form {@link //stdlib/gen_server} should be correct URIs for the on-line documentation. Affected versions All. Additional context Currently the produced links are of the form https://www.erlang.org/doc/apps/stdlib/doc/gen_server.html whereas the correct path would be https://www.erlang.org/doc/apps/stdlib/gen_server.html. The default base path is statically defined in the ?APP_DEFAULT macro, however that doesn't match the current on-line documentation. There is also a difference in the scheme for fragment identifiers used by edoc and the online-documentation. The edoc application uses a -1 suffix form for the arity portion while the on-line documentation uses /1. Possibly the best solution is for the on-

Describe the bug Unable to build Version 29.0 (and 28.5) on AIX 7.3 due to an issue in lib/parsetools/doc (make/doc.mk) During "make" following error arises === Entering application parsetools make[3]: Entering directory '/home/erlang/otp_src_29.0/lib/parsetools/src' make[3]: Nothing to be done for 'opt'. make[3]: Leaving directory '/home/erlang/otp_src_29.0/lib/parsetools/src' make[3]: Entering directory '/home/erlang/otp_src_29.0/lib/parsetools/doc' /home/erlang/otp_src_29.0/make/doc.mk:140: *** target pattern contains no '%'. Stop. make[3]: Leaving directory '/home/erlang/otp_src_29.0/lib/parsetools/doc' make[2]: *** [/home/erlang/otp_src_29.0/make/otp_subdir.mk:31: opt] Error 2 make[2]: Leaving directory '/home/erlang/otp_src_29.0/lib/parsetools' make[1]: *** [/home/erlang/otp_src_29.0/make/otp_subdir.mk:31: opt] Error 2 make[1]: Leaving directory '/home/erlang/otp_src_29.0/lib' make: *** [Makefile:685: secondary_bootstrap] Error 2 The values of the variables are: MAN1_DEPS, MAN4

Describe the bug I'm building Elixir using Fedora 43 RPM specs in a CentOS 10 environment on Loongarch64. In some rare cases a random test in the test suite fails with following error message: Compiling 2 files (.ex) Internal error: Invalid reference count found on #Fun<sys_core_fold.16.130330765>: About to erase fun still referred by code. Crash dump is being written to: erl_crash.dump...Lock order violation occurred when locking 'export_tab:[][mutex]'(none)! Currently these locks are locked by the scheduler 7 thread: 'proc_main:<0.140.0>[proclock](beam/erl_process.c:10075)'(none) 'fun_tab:[][rw_mutex](beam/erl_fun.c:182)'(none) Lock order: driver_lock:driver_name port_lock:port_id port_data_lock:address reg_tab proc_main:pid old_code:address nif_call_tab nodes_monitors meta_name_tab:address db_tab:address db_tab_fix:address db_hash_slot:address erl_db_catree_base_node erl_db_catree_route_node:index resource_monitors:address driver_list dist_ent

Is your feature request related to a problem? Please describe. The release_handler suspends the processes to be updated one by one with sys:suspend. At worst case, for N processes, this can take N*timeout. This delays the upgrade, and makes processes be suspended for longer than they'd need. Describe the solution you'd like Suspend the processes concurrently. Potentially run code_change concurrently too. Describe alternatives you've considered Doing this via a library. Additional context I'd be happy to contribute a patch, but I'm not sure about the design. I played a bit with the concept and understand it can be tricky.

I mean that would be very cool if one could use pattern matching in rules. Option 1 aggregate_windowed_function_name -> 'GROUPING' {keyword, _, 'ID'} : 'GROUPING_ID'. OR Option 2 aggregate_windowed_function_name -> 'GROUPING' elem(3, 'ID') : 'GROUPING_ID'. This possibility could be deadly killer feature when compared to the classic bison.

Provide a brief overview of what the new feature is all about If a _view has an impossible start_key/end_key combination we send a helpful error; {"error":"query_parse_error","reason":"No rows can match your key range, reverse your start_key and end_key or set descending=false","ref":457284027} We should do the same for _all_docs Tell us how the new feature should work. Be specific A similar check_range function when parsing query params of _all_docs calls, returning a 400 status code and the same error reason as for _view. Not required. Suggest how to implement the addition or change No response Additional Context No response