Lightning Internal Server Error Caused By Changing Return Type

Question

I've got an Apex controller method that returns a List<ReportLine> where ReportLine is a pretty simple custom class.

public class ReportLine
{
    @auraEnabled
    public String Name {get; set;}

    @auraEnabled
    public User UserInfo {get; set;}

    @auraEnabled
    public String Id {get; set;}

    @auraEnabled
    public Integer Sent {get; set;}

    @auraEnabled
    public Integer Opened {get; set;}

    @auraEnabled
    public Integer Replies {get; set;}

    @auraEnabled
    public Decimal AttributedSales {get; set;}

    public ReportLine()
    {
        Sent = 0;
        Opened = 0;
        Replies = 0;
        AttributedSales = 0.0;
    }
}

I want to change that method to return a wrapper class that includes the old List<ReportLine> value, but the moment I change the return type to the following wrapper class, I get an internal server error.

public class ReportData
{
    @auraEnabled
    public Map<Date, ReportLine> dailyTotals {get; set;}

    @auraEnabled
    public List<ReportLine> linesByEntity {get; set;}
}

Am I missing something obvious? Can you not return a type that's composed of another custom type? This is a pretty sub-standard development experience. I've tried wrapping the entire method body inside of a try/catch block to see if there was an exception being thrown, but it definitely appears to be related to the return type.

Edit

I suspect this is something particular to my org getting into a funky state somewhere. I've just stripped the Apex controller class down to this and I'm still getting the error:

public with sharing class OutreachReportServices
{
    public class ReportData
    {
        @auraEnabled
        public List<String> dailyTotals {get; set;}

        @auraEnabled
        public List<String> linesByEntity {get; set;}
    }

    @auraEnabled
    public static ReportData getLinesByStore(String type, Date rangeStart, Date rangeEnd)
    {
        return null;
    }
}

Answer 1

Well this might help somebody else, or it might not. Now that I know what's going on, it makes sense that the changing the return type was causing this issue. I'd neglected to notice (I set this code up a while ago) that the code I was modifying was in a services class, and not the Apex controller class that the Lightning controller was calling.

Changing this return type should have failed to save as it invalidated the other class, but for some reason it didn't, putting the other class into a broken state. Of course some logs to that effect would have been useful, but there was nothing in the front end or the dev console to suggest what was going on.