Describe the bug
Sending a test email with known working SMTP credentials causes the error dial failed: EOF, which eventually results in a fatal panic.
To Reproduce
Have main.exe open in a terminal window
In the GUI, go to the Alert tab and add a valid email to receive alerts at, then go to the SMTP tab and add known working SMTP credentials
Click Send Test Email
Expected behavior
A test email should be sent to the email in the Alerts tab - instead the following output is produced:
⇨ http server started on [::]:3124
{"time":"2024-10-24T21:48:14.7867453+01:00","id":"","remote_ip":"127.0.0.1","host":"localhost:3124","method":"GET","uri":"/config/alerts","user_agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:131.0) Gecko/20100101 Firefox/131.0","status":200,"error":"","latency":560
900,"latency_human":"560.9µs","bytes_in":0,"bytes_out":0}
{"time":"2024-10-24T21:48:16.5343045+01:00","id":"","remote_ip":"127.0.0.1","host":"localhost:3124","method":"GET","uri":"/config/smtp","user_agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:131.0) Gecko/20100101 Firefox/131.0","status":200,"error":"","latency":0,"la
tency_human":"0s","bytes_in":0,"bytes_out":0}
2024/10/24 21:48:16 🔄 Refreshing WHOIS cache
2024/10/24 21:48:17 Error parsing whois for https://www.watcheddomain.uk: whoisparser: domain whois data is invalid
2024/10/24 21:48:17 💾 Flushed WHOIS data cache to whois-cache.yaml
2024/10/24 21:48:17 💾 Flushed WHOIS data cache to whois-cache.yaml
2024/10/24 21:48:17 📆 Scheduler running WHOIS expiration checks every 4h0m0s
2024/10/24 21:48:30 failed to deliver mail: dial failed: EOF
2024/10/24 21:48:30 ❌ Failed to send test mail to myemail@example.com: dial failed: EOF
{"time":"2024-10-24T21:48:30.6773651+01:00","level":"ERROR","prefix":"echo","file":"error.handler.go","line":"15","message":"dial failed: EOF"}
{"time":"2024-10-24T21:48:30.7865444+01:00","id":"","remote_ip":"127.0.0.1","host":"localhost:3124","method":"POST","uri":"/mailer/test","user_agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:131.0) Gecko/20100101 Firefox/131.0","status":200,"error":"dial failed: EOF
","latency":10800009000,"latency_human":"10.800009s","bytes_in":0,"bytes_out":1443}
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x0 addr=0xd8 pc=0x799722]
goroutine 24 [running]:
main.domainExpirationCheckOnSchedule({{{0xc000002480, 0x3, 0x3}}, {0xc000014948, 0x17}}, {{{0xc00012ae00, 0x3, 0x3}}, {0xc000014858, 0x12}}, ...)
D:/Users/Hashim/Desktop/domain-monitor/cmd/main.go:127 +0x442
main.main.func2()
D:/Users/Hashim/Desktop/domain-monitor/cmd/main.go:102 +0x88
created by time.goFunc
C:/Program Files/Go/src/time/sleep.go:215 +0x2d
Desktop (please complete the following information):
OS: Windows 10 via Cygwin
Browser: Firefox 131.0.3
Additional context
It's possible that the error parsing https://www.watcheddomain.uk could also be contributing here, I notice now that I accidentally added it with the protocol instead of just the FQDN, but I'm now unable to edit or delete this entry from the GUI even on a fresh start of main.exe, so this is likely another separate bug that needs reporting.
I also notice that none of the files in assets/data have any config data inside of them, and deleting them doesn't seem to recreate them automatically as would be expected, so I'm not sure where it's being stored. On a server somewhere, or just in one of the files in the parent directory?
Describe the bug Sending a test email with known working SMTP credentials causes the error
dial failed: EOF
, which eventually results in a fatal panic.To Reproduce
Expected behavior A test email should be sent to the email in the Alerts tab - instead the following output is produced:
Desktop (please complete the following information):
Additional context It's possible that the error parsing
https://www.watcheddomain.uk
could also be contributing here, I notice now that I accidentally added it with the protocol instead of just the FQDN, but I'm now unable to edit or delete this entry from the GUI even on a fresh start ofmain.exe
, so this is likely another separate bug that needs reporting.I also notice that none of the files in
assets/data
have any config data inside of them, and deleting them doesn't seem to recreate them automatically as would be expected, so I'm not sure where it's being stored. On a server somewhere, or just in one of the files in the parent directory?